A plataforma Android 16 inclui mudanças de comportamento que podem afetar seu app.
As mudanças de comportamento a seguir se aplicam a todos os apps quando executados no Android 16,
independente da targetSdkVersion
. Teste o app e faça as modificações
necessárias para oferecer suporte a essas mudanças, quando aplicável.
Consulte também a lista de mudanças de comportamento que afetam apenas os apps destinados ao Android 16.
Principal recurso
O Android 16 inclui as seguintes mudanças que modificam ou expandem vários recursos principais do sistema Android.
Otimizações de cota do JobScheduler
A partir do Android 16, estamos ajustando a cota de execução de jobs regulares e acelerados com base nos seguintes fatores:
- Em qual bucket de espera do app o aplicativo está: no Android 16, os buckets de espera ativos vão começar a ser aplicados por uma cota de tempo de execução generosa.
- Se o job iniciar a execução enquanto o app estiver em um estado superior: no Android 16, os jobs iniciados enquanto o app está visível para o usuário e continuam depois que o app fica invisível vão aderir à cota de execução do job.
- Se o job estiver sendo executado enquanto um serviço em primeiro plano é executado: no Android 16, os jobs que estiverem sendo executados simultaneamente a um serviço em primeiro plano vão aderir à cota de execução do job. Se você estiver usando jobs para transferência de dados iniciada pelo usuário, considere usar jobs de transferência de dados iniciada pelo usuário.
Essa mudança afeta as tarefas programadas usando o WorkManager, o JobScheduler e o
DownloadManager. Para depurar o motivo da interrupção de um job, recomendamos registrar o motivo
chamando WorkInfo.getStopReason()
(para
jobs do JobScheduler, chame JobParameters.getStopReason()
).
Para mais informações sobre as práticas recomendadas para otimizar a bateria, consulte as orientações sobre como otimizar o uso da bateria para APIs de programação de tarefas.
Também recomendamos aproveitar a nova
API JobScheduler#getPendingJobReasonsHistory
introduzida no
Android 16 para entender por que um job não foi executado.
Teste
Para testar o comportamento do app, ative a substituição de determinadas otimizações de cota de jobs, desde que o app esteja sendo executado em um dispositivo Android 16.
Para desativar a aplicação de "o estado superior vai aderir à cota de execução do job", execute o
seguinte comando adb
:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME
Para desativar a aplicação de "jobs que estão sendo executados simultaneamente a um
serviço em primeiro plano vão aderir à cota de execução do job", execute o seguinte
comando adb
:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME
Para testar o comportamento de um bucket de espera de app, defina o bucket
do app usando o comando adb
a seguir:
adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted
Para entender o bucket de espera do app em que seu app está, é possível acessar o bucket
de espera do app usando o comando adb
a seguir:
adb shell am get-standby-bucket APP_PACKAGE_NAME
Suspensão total de JobInfo#setImportantWhileForeground
O método JobInfo.Builder#setImportantWhileForeground(boolean)
indica a importância de um job enquanto o app de programação está em primeiro plano
ou quando é temporariamente isento de restrições em segundo plano.
Esse método foi descontinuado a partir do Android 12 (nível 31 da API). A partir do Android 16, ele não funciona mais de forma eficaz, e a chamada desse método será ignorada.
Essa remoção de funcionalidade também se aplica a
JobInfo#isImportantWhileForeground()
. A partir do Android
16, se o método for chamado, ele retornará false
.
O escopo de prioridade de transmissão ordenada não é mais global
Android apps are allowed to define priorities on broadcast receivers to control
the order in which the receivers receive and process the broadcast. For
manifest-declared receivers, apps can use the
android:priority
attribute to define the priority and for
context-registered receivers, apps can use the
IntentFilter#setPriority()
API to define the priority. When
a broadcast is sent, the system delivers it to receivers in order of their
priority, from highest to lowest.
In Android 16, broadcast delivery order using the android:priority
attribute
or IntentFilter#setPriority()
across different processes will not be
guaranteed. Broadcast priorities will only be respected within the same
application process rather than across all processes.
Also, broadcast priorities will be automatically confined to the range
(SYSTEM_LOW_PRIORITY
+ 1,
SYSTEM_HIGH_PRIORITY
- 1). Only system components will be
allowed to set SYSTEM_LOW_PRIORITY
, SYSTEM_HIGH_PRIORITY
as broadcast
priority.
Your app might be impacted if it does either of the following:
- Your application has declared multiple processes with the same broadcast intent, and has expectations around receiving those intents in a certain order based on the priority.
- Your application process interacts with other processes and has expectations around receiving a broadcast intent in a certain order.
If the processes need to coordinate with each other, they should communicate using other coordination channels.
Alterações internas do ART
Android 16 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime's (ART's) performance and provide support for additional Java features. Through Google Play System updates, these improvements are also available to over a billion devices running Android 12 (API level 31) and higher.
As these changes are released, libraries and app code that rely on internal structures of ART might not work correctly on devices running Android 16, along with earlier Android versions that update the ART module through Google Play system updates.
Relying on internal structures (such as non-SDK interfaces) can always lead to compatibility problems, but it's particularly important to avoid relying on code (or libraries containing code) that leverages internal ART structures, since ART changes aren't tied to the platform version the device is running on and they go out to over a billion devices through Google Play system updates.
All developers should check whether their app is impacted by testing their apps thoroughly on Android 16. In addition, check the known issues to see if your app depends on any libraries that we've identified that rely on internal ART structures. If you do have app code or library dependencies that are affected, seek public API alternatives whenever possible and request public APIs for new use cases by creating a feature request in our issue tracker.
Experiência do usuário e interface do sistema
O Android 16 inclui as seguintes mudanças, que têm como objetivo criar uma experiência do usuário mais consistente e intuitiva.
Descontinuação dos avisos de acessibilidade que causam interrupção
Android 16 deprecates accessibility announcements, characterized by the use of
announceForAccessibility
or the dispatch of
TYPE_ANNOUNCEMENT
accessibility events. These can create
inconsistent user experiences for users of TalkBack and Android's screen reader,
and alternatives better serve a broader range of user needs across a variety of
Android's assistive technologies.
Examples of alternatives:
- For significant UI changes like window changes, use
Activity.setTitle(CharSequence)
andsetAccessibilityPaneTitle(java.lang.CharSequence)
. In Compose, useModifier.semantics { paneTitle = "paneTitle" }
- To inform the user of changes to critical UI, use
setAccessibilityLiveRegion(int)
. In Compose, useModifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]}
. These should be used sparingly as they may generate announcements every time a View is updated. - To notify users about errors, send an
AccessibilityEvent
of typeAccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR
and setAccessibilityNodeInfo#setError(CharSequence)
, or useTextView#setError(CharSequence)
.
The reference documentation for the deprecated
announceForAccessibility
API includes more details about
suggested alternatives.
Suporte à navegação com três botões
O Android 16 oferece suporte à volta preditiva na navegação de três botões para apps que foram migrados corretamente para a volta preditiva. Tocar e pressionar o botão "Voltar" inicia uma animação de volta preditiva, mostrando uma prévia de onde a ação de deslizar para trás vai levar você.
Esse comportamento se aplica a todas as áreas do sistema que oferecem suporte a animações de volta preditiva, incluindo as animações do sistema (volta à tela inicial, entre tarefas e entre atividades).