Esta página foi traduzida pela API Cloud Translation.

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

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

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:

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.
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 com o 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.

Se o Android detectar que o app tem páginas de memória alinhadas de 4 KB, ele usará automaticamente o modo de compatibilidade e exibirá 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 ter o melhor desempenho, confiabilidade e estabilidade, o app ainda precisa ter 16 KB. 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 inclui as seguintes mudanças, que têm como objetivo criar uma experiência do usuário mais consistente e intuitiva.

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.

Formatos de dispositivo

O Android 16 inclui as seguintes mudanças para apps quando projetados em telas pelos 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, os proprietários de dispositivos virtuais podem substituir as configurações do app em alguns dispositivos virtuais que eles gerenciam. 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 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 vítima, acionando ações privilegiadas ou ganhando acesso de URI a dados sensíveis, potencialmente levando 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 compilados com o SDK do Android 16 ou versões mais recentes

É 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 inclui as seguintes mudanças na pilha de Bluetooth para melhorar a conectividade com dispositivos periféricos.

Melhoria no tratamento de perda 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.