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 (nível 36 da API) inclui as seguintes mudanças que modificam ou expandem vários recursos principais do sistema Android.

Otimizações de cota do JobScheduler

Starting in Android 16, we're adjusting regular and expedited job execution runtime quota based on the following factors:

  • Which app standby bucket the application is in: in Android 16, active standby buckets will start being enforced by a generous runtime quota.
  • If the job starts execution while the app is in a top state: in Android 16, Jobs started while the app is visible to the user and continues after the app becomes invisible, will adhere to the job runtime quota.
  • If the job is executing while running a Foreground Service: in Android 16, jobs that are executing while concurrently with a foreground service will adhere to the job runtime quota. If you're leveraging jobs for user initiated data transfer, consider using user initiated data transfer jobs instead.

This change impacts tasks scheduled using WorkManager, JobScheduler, and DownloadManager. To debug why a job was stopped, we recommend logging why your job was stopped by calling WorkInfo.getStopReason() (for JobScheduler jobs, call JobParameters.getStopReason()).

For more information on battery-optimal best practices, refer to guidance on optimize battery use for task scheduling APIs.

We also recommend leveraging the new JobScheduler#getPendingJobReasonsHistory API introduced in Android 16 to understand why a job has not executed.

Testing

To test your app's behavior, you can enable override of certain job quota optimizations as long as the app is running on an Android 16 device.

To disable enforcement of "top state will adhere to job runtime quota", run the following adb command:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

To disable enforcement of "jobs that are executing while concurrently with a foreground service will adhere to the job runtime quota", run the following adb command:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

To test certain app standby bucket behavior, you can set the app standby bucket of your app using the following adb command:

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

To understand the app standby bucket your app is in, you can get the app standby bucket of your app using the following adb command:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motivo de interrupção de jobs vazios abandonados

An abandoned job occurs when the JobParameters object associated with the job has been garbage collected, but JobService#jobFinished(JobParameters, boolean) has not been called to signal job completion. This indicates that the job may be running and being rescheduled without the app's awareness.

Apps that rely on JobScheduler, don't maintain a strong reference to the JobParameters object, and timeout will now be granted the new job stop reason STOP_REASON_TIMEOUT_ABANDONED, instead of STOP_REASON_TIMEOUT.

If there are frequent occurrences of the new abandoned stop reason, the system will take mitigation steps to reduce job frequency.

Apps should use the new stop reason to detect and reduce abandoned jobs.

If you're using WorkManager, AsyncTask, or DownloadManager, you aren't impacted because these APIs manage the job lifecycle on your app's behalf.

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.

Modo de compatibilidade de tamanho de página de 16 KB

O Android 15 introduziu o suporte a páginas de memória de 16 KB para otimizar o desempenho da plataforma. O Android 16 adiciona um modo de compatibilidade, permitindo que alguns apps criados para páginas de memória de 4 KB sejam executados em um dispositivo configurado para páginas de memória de 16 KB.

Quando o app está em execução em um dispositivo com o Android 16 ou mais recente, se o Android detectar que o app tem páginas de memória alinhadas de 4 KB, ele vai usar automaticamente o modo de compatibilidade e mostrar uma caixa de diálogo de notificação para o usuário. Definir a propriedade android:pageSizeCompat no AndroidManifest.xml para ativar o modo de compatibilidade com versões anteriores vai impedir a exibição da caixa de diálogo quando o app for iniciado. Para usar a propriedade android:pageSizeCompat, compile o app usando o SDK do Android 16.

Para ter o melhor desempenho, confiabilidade e estabilidade, o app ainda precisa ter 16 KB alinhados. Confira nossa postagem recente do blog sobre como atualizar seus apps para oferecer suporte a páginas de memória de 16 KB para mais detalhes.

A caixa de diálogo do modo de compatibilidade que aparece quando o sistema detecta que um app alinhado a 4 KB pode ser executado de maneira mais otimizada se for alinhado a 16 KB.

Experiência do usuário e interface do sistema

O Android 16 (nível 36 da API) 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:

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.

Formatos de dispositivo

O Android 16 (nível 36 da API) inclui as seguintes mudanças para apps quando projetados em telas por proprietários de dispositivos virtuais.

Modificações do proprietário do dispositivo virtual

Um proprietário de dispositivo virtual é um app confiável ou privilegiado que cria e gerencia um dispositivo virtual. Os proprietários de dispositivos virtuais executam apps em um dispositivo virtual e, em seguida, projetam os apps na tela de um dispositivo remoto, como um computador pessoal, um dispositivo de realidade virtual ou um sistema de infoentretenimento de carro. O proprietário do dispositivo virtual está em um dispositivo local, como um smartphone.

O proprietário do dispositivo virtual no smartphone cria um dispositivo virtual que projeta o app na tela remota.

Substituições por app

Em dispositivos com o Android 16 (nível 36 da API), os proprietários de dispositivos virtuais podem substituir as configurações do app em alguns dispositivos virtuais que eles administram. Por exemplo, para melhorar o layout do app, um proprietário de dispositivo virtual pode ignorar restrições de orientação, proporção e redimensionamento ao projetar apps em uma tela externa.

Mudanças interruptivas comuns

O comportamento do Android 16 pode afetar a interface do app em fatores de forma de tela grande, como telas de carro ou Chromebooks, principalmente layouts projetados para telas pequenas na orientação retrato. Para saber como tornar seu app adaptável a todos os formatos de dispositivo, consulte Sobre layouts adaptáveis.

Referências

Streaming de apps complementares

Segurança

O Android 16 (nível 36 da API) inclui mudanças que promovem a segurança do sistema para ajudar a proteger apps e usuários contra apps maliciosos.

Melhoria da segurança contra ataques de redirecionamento de intent

O Android 16 oferece segurança padrão contra ataques de redirecionamento Intent gerais, com compatibilidade mínima e alterações necessárias para desenvolvedores.

Estamos introduzindo soluções de aumento de proteção de segurança por padrão para ataques de redirecionamento Intent. Na maioria dos casos, os apps que usam intents normalmente não têm problemas de compatibilidade. Coletamos métricas durante o processo de desenvolvimento para monitorar quais apps podem apresentar falhas.

O redirecionamento de intents no Android ocorre quando um invasor pode controlar total ou parcialmente o conteúdo de uma intent usada para iniciar um novo componente no contexto de um app vulnerável, enquanto o app vítima inicia uma intent de subnível não confiável em um campo "Extras" de uma intent ("de nível superior"). Isso pode levar o app do invasor a iniciar componentes particulares no contexto do app da vítima, acionando ações privilegiadas ou ganhando acesso de URI a dados sensíveis, o que pode levar ao roubo de dados e à execução arbitrária de código.

Desativar o processamento de redirecionamento de intents

O Android 16 apresenta uma nova API que permite que os apps desativem as proteções de segurança de inicialização. Isso pode ser necessário em casos específicos em que o comportamento de segurança padrão interfere em casos de uso legítimos de apps.

Para aplicativos que compilam com o SDK do Android 16 (nível 36 da API) ou mais recente

É possível usar o método removeLaunchSecurityProtection() diretamente no objeto Intent.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
Para aplicativos que são compilados para o Android 15 (nível 35 da API) ou versões anteriores

Embora não seja recomendado, você pode usar a reflexão para acessar o método removeLaunchSecurityProtection().

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

Conectividade

O Android 16 (nível 36 da API) inclui as seguintes mudanças na pilha de Bluetooth para melhorar a conectividade com dispositivos periféricos.

Melhoria no tratamento de perdas de títulos

A partir do Android 16, a pilha Bluetooth foi atualizada para melhorar a segurança e a experiência do usuário quando uma perda de vínculo remoto é detectada. Antes, o sistema retirava automaticamente a vinculação e iniciava um novo processo de pareamento, o que poderia levar a um novo pareamento não intencional. Em muitos casos, os apps não tratavam o evento de perda de vínculo de forma consistente.

Para unificar a experiência, o Android 16 melhorou o processamento de perda de vínculo para o sistema. Se um dispositivo Bluetooth pareado anteriormente não puder ser autenticado na reconexão, o sistema desconectará o link, manterá as informações de pareamento local e exibirá uma caixa de diálogo do sistema informando os usuários sobre a perda de pareamento e orientando-os a fazer o pareamento novamente.