Mudanças de comportamento: todos os apps

A plataforma Android 16 inclui mudanças de comportamento que podem afetar seu app. As mudanças a seguir se aplicam a todos os apps quando executados no Android 16, independente da targetSdkVersion. Teste seu app e modifique-o conforme necessário para que ele ofereça suporte a essas mudanças.

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

Principal recurso

O Android 16 (API de nível 36) 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 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 information about how your app's state affects the resources it can use, see Power management resource limits. 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 da 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

JobInfo.Builder#setImportantWhileForeground(boolean) 方法用于在调度应用位于前台或暂时豁免于后台限制时指示作业的优先级。

自 Android 12（API 级别 31）起，此方法已废弃。从 Android 16 开始，它不再有效，系统会忽略调用此方法。

此功能移除也适用于 JobInfo#isImportantWhileForeground()。从 Android 16 开始，如果调用该方法，该方法会返回 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.

Mudanças internas no ART

Android 16 包含 Android 运行时 (ART) 的最新更新，这些更新可提升 Android 运行时 (ART) 的性能，并支持更多 Java 功能。通过 Google Play 系统更新，搭载 Android 12（API 级别 31）及更高版本的 10 亿多部设备也将受益于这些改进。

发布这些变更后，依赖于 ART 内部结构的库和应用代码在搭载 Android 16 的设备以及通过 Google Play 系统更新来更新 ART 模块的较低 Android 版本上可能无法正常运行。

依赖于内部结构（例如非 SDK 接口）始终会导致兼容性问题，但避免依赖于利用内部 ART 结构的代码（或包含代码的库）尤为重要，因为 ART 更改与设备所运行的平台版本无关，并且会通过 Google Play 系统更新推送到超过 10 亿部设备。

所有开发者都应在 Android 16 上对其应用进行全面测试，以检查其应用是否受到影响。此外，请查看已知问题，了解您的应用是否依赖于我们发现的任何依赖于内部 ART 结构的库。如果您的应用代码或库依赖项受到影响，请尽可能寻找公共 API 替代方案，并在问题跟踪器中创建功能请求，为新用例请求公共 API。

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 visam criar uma experiência do usuário mais consistente e intuitiva.

Descontinuação de 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) and setAccessibilityPaneTitle(java.lang.CharSequence). In Compose, use Modifier.semantics { paneTitle = "paneTitle" }
• To inform the user of changes to critical UI, use setAccessibilityLiveRegion(int). In Compose, use Modifier.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 type AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR and set AccessibilityNodeInfo#setError(CharSequence), or use TextView#setError(CharSequence).

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

Compatibilidade com a 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.

Í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 projetam os apps na tela de um dispositivo remoto, como um computador pessoal, um dispositivo de realidade virtual ou um sistema de infoentretenimento do 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 em uma tela remota.

Substituições por app

Em dispositivos com o Android 16 (nível da API 36), 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 interruptivas comuns

O comportamento do Android 16 pode afetar a interface do seu app em formatos de tela grande, como telas de carro 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 da API 36) 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 intent

Android 16 提供了针对一般 Intent 重定向攻击的默认安全性，并且只需进行最低限度的兼容性更改和开发者更改。

我们正在引入默认安全强化解决方案，以应对Intent重定向漏洞。在大多数情况下，使用 intent 的应用通常不会遇到任何兼容性问题；我们在整个开发过程中收集了指标，以监控哪些应用可能会出现中断。

当攻击者可以部分或完全控制用于在存在漏洞的应用上下文中启动新组件的 intent 内容时，就会出现 Android 中的 intent 重定向问题，而受害应用会在（“顶级”）intent 的 extras 字段中启动不可信的子级 intent。这可能会导致攻击者应用在受害者应用的上下文中启动私有组件、触发特权操作或获得对敏感数据的 URI 访问权限，从而可能导致数据窃取和任意代码执行。

选择停用 intent 重定向处理

Android 16 引入了一项新 API，允许应用选择停用启动安全保护功能。在默认安全行为会干扰正当应用用例的特定情况下，这可能是必要的。

重要提示： 退出安全保护功能时应谨慎行事，并且仅在绝对必要时才应这样做，因为这可能会增加出现安全漏洞的风险。请在调用此 API 之前仔细评估其对应用安全性的潜在影响。

对于针对 Android 16（API 级别 36）SDK 或更高版本进行编译的应用

您可以直接对 Intent 对象使用 removeLaunchSecurityProtection() 方法。

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

对于针对 Android 15（API 级别 35）或更低版本进行编译的应用

虽然不建议这样做，但您可以使用反射来访问 removeLaunchSecurityProtection() 方法。

注意： 使用反射可能会使您的代码更加脆弱且容易出错，尤其是在未来的 Android 版本中底层 API 发生变化时。请尽可能更新编译 SDK，以将 Android 16（API 级别 36）或更高级别作为目标平台，从而直接使用该 API。

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

Os apps complementares não recebem mais notificações de tempo limite de descoberta

Android 16 在配套设备配对流程期间引入了一种新行为，以防恶意应用侵犯用户的位置信息隐私。在 Android 16 上运行的所有配套应用都不再直接通过 RESULT_DISCOVERY_TIMEOUT 收到发现超时通知。而是通过可视对话框通知用户超时事件。当用户关闭对话框时，系统会通过 RESULT_USER_REJECTED 提醒应用关联失败。

搜索时长也从原来的 20 秒延长到了 30 秒，并且用户可以在搜索期间的任何时间停止设备发现。如果在开始搜索的前 20 秒内发现了至少 1 部设备，CDM 会停止搜索其他设备。

Conectividade

O Android 16 (nível 36 da API) inclui as seguintes mudanças na pilha 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.