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 de targetSdkVersion. Teste seu app e modifique-o conforme necessário para ficar compatível com essas mudanças, se necessário.

Consulte também a lista de mudanças de comportamento que afetam apenas os apps destinados ao Android 16.

Funcionalidade principal

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

A partir do Android 16, vamos ajustar a cota de tempo 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 começar a execução enquanto o app estiver em um estado superior: no Android 16, os jobs iniciados enquanto o app estiver visível para o usuário e continuarem depois que o app ficar invisível vão obedecer à cota de tempo de execução do job.
  • Se o job estiver sendo executado com um serviço em primeiro plano: no Android 16, os jobs que estiverem sendo executados simultaneamente com um serviço em primeiro plano vão obedecer à cota de tempo 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 tarefas programadas usando o WorkManager, o JobScheduler e o DownloadManager. Para depurar por que um job foi interrompido, recomendamos registrar por que ele foi interrompido chamando WorkInfo.getStopReason() (para jobs do JobScheduler, chame JobParameters.getStopReason()).

Para saber como o estado do app afeta os recursos que ele pode usar, consulte Limites de recursos de gerenciamento de energia. Para mais informações sobre práticas recomendadas de otimização da bateria, consulte as orientações sobre como otimizar o uso da bateria para APIs de programação de tarefas.

Também recomendamos usar 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, é possível ativar a substituição de determinadas otimizações de cota de jobs enquanto o app estiver sendo executado em um dispositivo Android 16.

Para desativar a aplicação de "o estado principal vai obedecer à cota de tempo 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 em execução simultânea com um serviço em primeiro plano vão obedecer à cota de tempo 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 determinado comportamento do bucket de espera do app, defina o bucket de espera do app usando o seguinte comando adb:

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

Para entender em qual bucket de espera seu app está, use o seguinte comando adb:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motivo de interrupção de jobs vazios abandonados

Um job abandonado ocorre quando o objeto JobParameters associado ao job é coletado, mas JobService#jobFinished(JobParameters, boolean) não é chamado para sinalizar a conclusão do job. Isso indica que o job pode estar sendo executado e reprogramado sem que o app saiba.

Os apps que dependem do JobScheduler não mantêm uma referência forte ao objeto JobParameters, e o tempo limite agora será concedido ao novo motivo de interrupção de job STOP_REASON_TIMEOUT_ABANDONED, em vez de STOP_REASON_TIMEOUT.

Se houver ocorrências frequentes do novo motivo de interrupção, o sistema vai tomar medidas de mitigação para reduzir a frequência do job.

Os apps precisam usar o novo motivo de interrupção para detectar e reduzir jobs abandonados.

Se você estiver usando o WorkManager, o AsyncTask ou o DownloadManager, não será afetado porque essas APIs gerenciam o ciclo de vida do job em nome do app.

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:

  1. 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.
  2. 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.

Mudanças 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.

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

Android 15 introduced support for 16 KB memory pages to optimize performance of the platform. Android 16 adds a compatibility mode, allowing some apps built for 4 KB memory pages to run on a device configured for 16 KB memory pages.

When your app is running on a device with Android 16 or higher, if Android detects that your app has 4 KB aligned memory pages, it automatically uses compatibility mode and display a notification dialog to the user. Setting the android:pageSizeCompat property in the AndroidManifest.xml to enable the backwards compatibility mode will prevent the display of the dialog when your app launches. To use the android:pageSizeCompat property, compile your app using the Android 16 SDK.

For best performance, reliability, and stability, your app should still be 16 KB aligned. Check out our recent blog post on updating your apps to support 16 KB memory pages for more details.

The compatibility mode dialog that displays when the system detects that a 4 KB-aligned app could run more optimally if 16 KB aligned.

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.

Suspensão de anúncios de acessibilidade disruptivos

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:

The reference documentation for the deprecated announceForAccessibility API includes more details about suggested alternatives.

Suporte à navegação com três botões

Android 16 brings predictive back support to the 3-button navigation for apps that have properly migrated to predictive back. Long-pressing the back button initiates a predictive back animation, giving you a preview of where the back swipe takes you.

This behavior applies across all areas of the system that support predictive back animations, including the system animations (back-to-home, cross-task, and cross-activity).

The predictive back animations in 3-button navigation mode.

Ícones temáticos automáticos de apps

A partir do Android 16 QPR 2, o Android aplica temas automaticamente aos ícones de apps para criar uma experiência coesa na tela inicial. Isso acontece se um app não fornecer um ícone temático próprio. Os apps podem controlar o design do ícone temático incluindo uma camada monocromática no ícone adaptável e conferindo uma prévia da aparência do ícone no Android Studio.

Formatos de dispositivos

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.

Substituiçõ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 os projetam na tela de um dispositivo remoto, como um computador pessoal, um dispositivo de realidade virtual ou um sistema de infoentretenimento automotivo. 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 de apps em dispositivos virtuais selecionados que eles gerenciam. Por exemplo, para melhorar o layout do app, um proprietário de dispositivo virtual pode ignorar as restrições de orientação, proporção e redimensionamento ao projetar apps em uma tela externa.

Mudanças importantes comuns

O comportamento do Android 16 pode afetar a interface do app em formatos de tela grande, como telas de carros ou Chromebooks, especialmente layouts projetados para telas pequenas na orientação retrato. Para saber como tornar seu app adaptável a todos os formatos de dispositivos, 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.

Segurança aprimorada contra ataques de redirecionamento de intents

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

Estamos introduzindo soluções de reforço da proteção de segurança padrão para exploits de redirecionamento de Intent. Na maioria dos casos, os apps que usam intents normalmente não apresentam problemas de compatibilidade. Coletamos métricas durante todo 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 da vítima inicia uma intent de subnível não confiável em um campo de extras de uma intent ("de nível superior"). Isso pode levar o app 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 de código arbitrário.

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 do app.

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

Você pode usar diretamente o método removeLaunchSecurityProtection() 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 compilados com 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) }

Apps complementares não são mais notificados sobre tempos limite de descoberta

O Android 16 apresenta um novo comportamento durante o fluxo de pareamento de dispositivos complementares para proteger a privacidade de localização do usuário contra apps maliciosos. Todos os apps complementares em execução no Android 16 não são mais notificados diretamente do tempo limite de descoberta usando RESULT_DISCOVERY_TIMEOUT. Em vez disso, o usuário é notificado sobre eventos de tempo limite com uma caixa de diálogo visual. Quando o usuário dispensa a caixa de diálogo, o app é alertado sobre a falha de associação com RESULT_USER_REJECTED.

A duração da pesquisa também foi estendida em relação aos 20 segundos originais, e a descoberta de dispositivos pode ser interrompida pelo usuário a qualquer momento durante a pesquisa. Se pelo menos um dispositivo for descoberto nos primeiros 20 segundos após o início da pesquisa, o CDM vai parar de procurar outros dispositivos.

Conectividade

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

Tratamento aprimorado de perda de vínculo

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.