Mudanças de comportamento: todos os apps

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

Os apps Android podem definir prioridades em broadcast receivers para controlar a ordem em que os receptores recebem e processam a transmissão. Para recebedores declarados no manifesto, os apps podem usar o atributo android:priority para definir a prioridade. Para recebedores registrados no contexto, os apps podem usar a API IntentFilter#setPriority() para definir a prioridade. Quando uma transmissão é enviada, o sistema a entrega aos receptores na ordem de prioridade, da mais alta para a mais baixa.

No Android 16, a ordem de entrega de transmissão usando o atributo android:priority ou IntentFilter#setPriority() em diferentes processos não será garantida. As prioridades de transmissão só serão respeitadas no mesmo processo do aplicativo, e não em todos os processos.

Além disso, as prioridades de transmissão serão automaticamente limitadas ao intervalo (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Somente os componentes do sistema poderão definir SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY como prioridade de transmissão.

O app pode ser afetado se fizer o seguinte:

1. Seu aplicativo declarou vários processos com a mesma intent de transmissão e tem expectativas em relação ao recebimento dessas intents em uma determinada ordem com base na prioridade.
2. O processo do aplicativo interage com outros processos e tem expectativas em relação ao recebimento de uma intent de transmissão em uma determinada ordem.

Se os processos precisarem se coordenar, eles vão precisar se comunicar usando outros canais de coordenação.

Alterações internas do ART

O Android 16 inclui as atualizações mais recentes do Android Runtime (ART), que melhoram a performance do Android Runtime (ART) e oferecem suporte a outros recursos Java. Com as atualizações do sistema do Google Play, essas melhorias também estão disponíveis para mais de um bilhão de dispositivos com o Android 12 (nível 31 da API) e versões mais recentes.

À medida que essas mudanças são lançadas, bibliotecas e códigos de apps que dependem de estruturas internas do ART podem não funcionar corretamente em dispositivos com o Android 16, além de versões anteriores do Android que atualizam o módulo ART por meio de atualizações do sistema do Google Play.

A dependência de estruturas internas (como interfaces não SDK) pode sempre levar a problemas de compatibilidade, mas é particularmente importante evitar depender de código (ou bibliotecas que contenham código) que aproveite estruturas internas do ART, já que as mudanças do ART não estão vinculadas à versão da plataforma em que o dispositivo está executando e são enviadas para mais de um bilhão de dispositivos por meio de atualizações do sistema do Google Play.

Todos os desenvolvedores precisam verificar se o app é afetado testando-o completamente no Android 16. Além disso, verifique os problemas conhecidos para verificar se o app depende de bibliotecas que identificamos como dependentes de estruturas internas do ART. Se você tiver dependências de biblioteca ou código de app que foram afetadas, procure alternativas de API pública sempre que possível e solicite APIs públicas para novos casos de uso criando uma solicitação de recurso no nosso rastreador de problemas.

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

O Android 16 descontinua os avisos de acessibilidade, caracterizados pelo uso de announceForAccessibility ou o envio de eventos de acessibilidade TYPE_ANNOUNCEMENT. Isso pode criar experiências de usuário inconsistentes para usuários do TalkBack e do leitor de tela do Android. As alternativas atendem melhor a uma gama mais ampla de necessidades dos usuários em várias tecnologias assistivas do Android.

Exemplos de alternativas:

• Para mudanças significativas na interface, como mudanças de janela, use Activity.setTitle(CharSequence) e setAccessibilityPaneTitle(java.lang.CharSequence). No Compose, use Modifier.semantics { paneTitle = "paneTitle" }.
• Para informar o usuário sobre mudanças na interface crítica, use setAccessibilityLiveRegion(int). No Compose, use Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . Elas devem ser usadas com moderação, porque podem gerar avisos sempre que uma visualização é atualizada.
• Para notificar os usuários sobre erros, envie um AccessibilityEvent do tipo AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR e defina AccessibilityNodeInfo#setError(CharSequence) ou use TextView#setError(CharSequence).

A documentação de referência da API announceForAccessibility, que foi descontinuada, inclui mais detalhes sobre as alternativas sugeridas.

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).

As animações de volta preditiva no modo de navegação com três botões.