Mudanças de comportamento: apps destinados ao Android 16 ou versões mais recentes

Como nas versões anteriores, o Android 16 inclui mudanças de comportamento que podem afetar seu app. As seguintes mudanças de comportamento se aplicam exclusivamente a apps destinados ao Android 16 ou mais recente. Caso seu app seja direcionado ao Android 16 ou a versões mais recentes, faça modificações para oferecer suporte a esses comportamentos, quando aplicável.

Consulte também a lista de mudanças de comportamento que afetam todos os apps executados no Android 16, independente da targetSdkVersion do app.

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.

A opção de desativar a exibição de ponta a ponta foi removida

O Android 15 forçou a tela de ponta a ponta para apps direcionados ao Android 15 (nível 35 da API), mas seu app pode desativar essa configuração definindo R.attr#windowOptOutEdgeToEdgeEnforcement como true. Para apps direcionados ao Android 16 (nível 36 da API), R.attr#windowOptOutEdgeToEdgeEnforcement foi descontinuado e desativado, e o app não pode desativar a exibição de borda a borda.

  • Se o app for destinado ao Android 16 (nível 36 da API) e estiver sendo executado em um dispositivo com o Android 15, o R.attr#windowOptOutEdgeToEdgeEnforcement vai continuar funcionando.
  • Se o app for direcionado ao Android 16 (nível 36 da API) e estiver sendo executado em um dispositivo com o Android 16, o R.attr#windowOptOutEdgeToEdgeEnforcement será desativado.

Para testar no Android 16 Beta 3, verifique se o app oferece suporte a tela de ponta a ponta e remova qualquer uso de R.attr#windowOptOutEdgeToEdgeEnforcement para que ele também ofereça suporte a tela de ponta a ponta em um dispositivo Android 15. Para oferecer suporte a tela cheia, consulte as orientações de Compose e Views.

Migração ou desativação necessária para a volta preditiva

Para apps direcionados ao Android 16 (nível 36 da API) ou mais recente e executados em um dispositivo Android 16 ou mais recente, as animações de volta preditiva do sistema (voltar para a tela inicial, entre tarefas e entre atividades) são ativadas por padrão. Além disso, onBackPressed não é mais chamado e KeyEvent.KEYCODE_BACK não é mais enviado.

Se o app interceptar o evento de volta e você ainda não tiver migrado para a volta preditiva, atualize o app para usar APIs de navegação de volta compatíveis. Ou desative temporariamente definindo o atributo android:enableOnBackInvokedCallback como false na tag <application> ou <activity> do arquivo AndroidManifest.xml do app.

A animação preditiva de volta à página inicial.
A animação preditiva entre atividades.
A animação preditiva entre tarefas.

APIs de fonte elegante descontinuadas e desativadas

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

elegantTextHeight behavior for apps targeting Android 14 (API level 34) and lower, or for apps targeting Android 15 (API level 35) that overrode the default by setting the elegantTextHeight attribute to false.
elegantTextHeight behavior for apps targeting Android 16, or for apps targeting Android 15 (API level 35) that didn't override the default by setting the elegantTextHeight attribute to false.

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ção da programação de trabalho de taxa fixa

Antes de segmentar o Android 16, quando o scheduleAtFixedRate perdia uma execução de tarefa por estar fora de um ciclo de vida do processo válido, todas as execuções perdidas eram executadas imediatamente quando o app retornava a um ciclo de vida válido.

Ao segmentar o Android 16, no máximo uma execução perdida de scheduleAtFixedRate é executada imediatamente quando o app retorna a um ciclo de vida válido. Essa mudança de comportamento deve melhorar o desempenho do app. Teste esse comportamento no seu app para verificar se ele é afetado. Também é possível testar usando o framework de compatibilidade de apps e ativando a flag de compatibilidade STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Formatos de dispositivo

O Android 16 (nível 36 da API) inclui as seguintes mudanças para apps quando exibidos em dispositivos de tela grande.

Layouts adaptáveis

With Android apps now running on a variety of devices (such as phones, tablets, foldables, desktops, cars, and TVs) and windowing modes on large screens (such as split screen and desktop windowing), developers should build Android apps that adapt to any screen and window size, regardless of device orientation. Paradigms like restricting orientation and resizability are too restrictive in today's multidevice world.

Ignore orientation, resizability, and aspect ratio restrictions

For apps targeting Android 16 (API level 36), Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply. Apps also fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.

This change introduces a new standard platform behavior. Android is moving toward a model where apps are expected to adapt to various orientations, display sizes, and aspect ratios. Restrictions like fixed orientation or limited resizability hinder app adaptability, so we recommend making your app adaptive to deliver the best possible user experience.

You can also test this behavior by using the app compatibility framework and enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT compat flag.

Common breaking changes

Ignoring orientation, resizability, and aspect ratio restrictions might impact your app's UI on some devices, especially elements that were designed for small layouts locked in portrait orientation: for example, issues like stretched layouts and off-screen animations and components. Any assumptions about aspect ratio or orientation can cause visual issues with your app. Learn more about how to avoid them and improve your app's adaptive behaviour.

Allowing device rotation results in more activity re-creation, which can result in losing user state if not properly preserved. Learn how to correctly save UI state in Save UI states.

Implementation details

The following manifest attributes and runtime APIs are ignored across large screen devices in full-screen and multi-window modes:

The following values for screenOrientation, setRequestedOrientation(), and getRequestedOrientation() are ignored:

  • portrait
  • reversePortrait
  • sensorPortrait
  • userPortrait
  • landscape
  • reverseLandscape
  • sensorLandscape
  • userLandscape

Regarding display resizability, android:resizeableActivity="false", android:minAspectRatio, and android:maxAspectRatio have no effect.

For apps targeting Android 16 (API level 36), app orientation, resizability, and aspect ratio constraints are ignored on large screens by default, but every app that isn't fully ready can temporarily override this behavior by opting out (which results in the previous behavior of being placed in compatibility mode).

Exceptions

The Android 16 orientation, resizability, and aspect ratio restrictions don't apply in the following situations:

  • Games (based on the android:appCategory flag)
  • Users explicitly opting in to the app's default behavior in aspect ratio settings of the device
  • Screens that are smaller than sw600dp

Opt out temporarily

To opt out a specific activity, declare the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

If too many parts of your app aren't ready for Android 16, you can opt out completely by applying the same property at the application level:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Saúde e fitness

O Android 16 (nível 36 da API) inclui as seguintes mudanças relacionadas a dados de saúde e condicionamento físico.

Permissões de saúde e fitness

Para apps destinados ao Android 16 (nível 36 da API) ou mais recente, as permissões BODY_SENSORS estão sendo substituídas pelas permissões granulares em android.permissions.health, também usadas pela Conexão Saúde. Qualquer API que antes exigia BODY_SENSORS ou BODY_SENSORS_BACKGROUND agora precisa da permissão android.permissions.health correspondente. Isso afeta os seguintes tipos de dados, APIs e tipos de serviço em primeiro plano:

Se o app usar essas APIs, ele precisará solicitar as permissões granulares respectivas:

Essas permissões são as mesmas que protegem o acesso à leitura de dados da Conexão Saúde, o repositório de dados do Android para dados de saúde, fitness e bem-estar.

Apps para dispositivos móveis

Os apps para dispositivos móveis que migram para usar a READ_HEART_RATE e outras permissões granulares também precisam declarar uma atividade para mostrar a Política de Privacidade do app. Esse é o mesmo requisito da Conexão Saúde.

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.

Novas intents para lidar com perda de vínculo e mudanças de criptografia

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

  • Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
  • Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

If your app currently uses custom mechanisms for bond loss handling, migrate to the new intent ACTION_KEY_MISSING to detect and manage bond loss events. We recommend your app guide the user to confirm the remote device is in range before initiating device forgetting and re-pairing.

Moreover, if a device disconnects after ACTION_KEY_MISSING intent is received, your app should be mindful about reconnecting to the device as that device may no longer be bonded with the system.

Segurança

O Android 16 (nível 36 da API) inclui as seguintes mudanças de segurança.

Bloqueio de versão da MediaStore

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

Privacidade

O Android 16 (nível 36 da API) inclui as seguintes mudanças de privacidade.

Permissão de rede local

Os dispositivos na LAN podem ser acessados por qualquer app que tenha a permissão INTERNET. Isso facilita a conexão de apps a dispositivos locais, mas também tem implicações de privacidade, como a formação de uma impressão digital do usuário e a criação de um proxy para localização.

O objetivo do projeto de proteções de rede local é proteger a privacidade do usuário limitando o acesso à rede local com uma nova permissão de execução.

Plano de lançamento

Essa mudança será implantada entre duas versões, 25Q2 e TBD, respectivamente. É fundamental que os desenvolvedores sigam essas orientações para o 25Q2 e compartilhem feedback, porque essas proteções serão aplicadas em uma versão mais recente do Android. Além disso, eles vão precisar atualizar os cenários que dependem do acesso local implícito à rede usando as orientações a seguir e se preparar para a rejeição do usuário e a revogação da nova permissão.

Impacto

No momento, o LNP é um recurso opcional, o que significa que apenas os apps que forem ativados serão afetados. O objetivo da fase de ativação é que os desenvolvedores de apps entendam quais partes do app dependem do acesso implícito à rede local para que eles possam se preparar para a proteção por permissão na próxima versão.

Os apps serão afetados se acessarem a rede local do usuário usando:

  • Uso direto ou de biblioteca de soquetes brutos em endereços de rede local (por exemplo, protocolo de descoberta de serviço mDNS ou SSDP)
  • Uso de classes no nível do framework que acessam a rede local (por exemplo, NsdManager)

O tráfego para e de um endereço de rede local requer permissão de acesso à rede local. A tabela a seguir lista alguns casos comuns:

Operação de rede de baixo nível do app Permissão da rede local necessária
Como fazer uma conexão TCP de saída sim
Aceitar conexões TCP de entrada sim
Como enviar um unicast, multicast ou broadcast UDP sim
Receber um unicast, multicast ou broadcast UDP sim

Essas restrições são implementadas profundamente na pilha de rede e, portanto, se aplicam a todas as APIs de rede. Isso inclui soquetes criados em código nativo ou gerenciado, bibliotecas de rede, como Cronet e OkHttp, e qualquer API implementada em cima delas. Tentar resolver serviços na rede local (ou seja, aqueles com um sufixo .local) vai exigir permissão de rede local.

Exceções às regras acima:

  • Se o servidor DNS de um dispositivo estiver em uma rede local, o tráfego para ou dele (na porta 53) não vai exigir permissão de acesso à rede local.
  • Os aplicativos que usam o Output Switcher como seletor no app não precisarão de permissões de rede local (mais orientações serão enviadas no 4º trimestre de 2025).

Orientações para desenvolvedores (ativação)

Para ativar as restrições de rede local, faça o seguinte:

  1. Atualize o dispositivo para um build com a versão 25Q2 Beta 3 ou mais recente.
  2. Instale o app a ser testado.

  3. Alterne a flag Appcompat no adb:

    adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

  4. Reiniciar o dispositivo

Agora o acesso do app à rede local está restrito, e qualquer tentativa de acesso à rede local vai gerar erros de soquete. Se você estiver usando APIs que realizam operações de rede local fora do processo do app (por exemplo, NsdManager), elas não serão afetadas durante a fase de ativação.

Para restaurar o acesso, conceda ao app a permissão NEARBY_WIFI_DEVICES.

  1. Verifique se o app declara a permissão NEARBY_WIFI_DEVICES no manifesto.
  2. Acesse Configurações > Apps > [Nome do aplicativo] > Permissões > Dispositivos por perto > Permitir.

Agora, o acesso do app à rede local será restaurado, e todos os cenários vão funcionar como antes de ativar o app.

Quando a aplicação da proteção de rede local começar, o tráfego de rede do app será afetado da seguinte forma.

Permissão Solicitação de LAN de saída Solicitação de Internet de saída/entrada Solicitação de LAN de entrada
Concedido Works Works Works
Não concedido Falhas Works Falhas

Use o comando a seguir para desativar a flag "App-Compat".

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Erros

Erros decorrentes dessas restrições serão retornados ao soquete de chamada sempre que ele invocar o envio ou uma variante de envio para um endereço de rede local.

Exemplos de erros:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definição de rede local

Uma rede local neste projeto se refere a uma rede IP que utiliza uma interface de rede com capacidade de transmissão, como Wi-Fi ou Ethernet, mas exclui conexões celulares (WWAN) ou VPN.

As seguintes são consideradas redes locais:

IPv4:

  • 169.254.0.0/16 // Link Local
  • 100.64.0.0/10 // CGNAT
  • 10.0.0.0/8 // RFC1918
  • 172.16.0.0/12 // RFC1918
  • 192.168.0.0/16 // RFC1918

IPv6:

  • Link-local
  • Rotas conectadas diretamente
  • Redes stub, como Thread
  • Várias sub-redes (a ser definido)

Além disso, os dois endereços multicast (224.0.0.0/4, ff00::/8) e o endereço de transmissão IPv4 (255.255.255.255) são classificados como endereços de rede locais.