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 mudanças de comportamento a seguir se aplicam exclusivamente a apps destinados ao Android 16 ou versões mais recentes. Se o app for 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 seu app.

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.

A opção de recusa de ponta a ponta vai ser desativada

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

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

Em 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 preditivas do sistema de retorno (voltar para a tela inicial, entre tarefas e entre atividades) são ativadas por padrão. Além disso, onBackPressed não é chamado, e KeyEvent.KEYCODE_BACK não é mais enviado.

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

APIs de fontes elegantes descontinuadas e desativadas

Os apps destinados ao Android 15 (nível 35 da API) têm o atributo elegantTextHeight TextView definido como true por padrão, substituindo a fonte compacta por uma muito mais legível. É possível substituir isso definindo o atributo elegantTextHeight como false.

O Android 16 descontinua o atributo elegantTextHeight, que será ignorado quando o app for destinado ao Android 16. As "fontes da interface" controladas por essas APIs serão descontinuadas. Por isso, adapte todos os layouts para garantir a renderização de texto consistente e à prova de futuro em árabe, laosiano, birmanês, tâmil, gujarati, canarês, malaiala, odia, télugo ou tailandês.

Comportamento de

Comportamento de

Principal recurso

O Android 16 (nível da API 36) inclui as seguintes mudanças que modificam ou ampliam vários recursos principais do sistema Android.

Otimização de programação de trabalho com 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 dispositivos

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

Layouts adaptáveis

Com os apps Android agora sendo executados em vários dispositivos (como smartphones, tablets, dobráveis, computadores, carros e TVs) e modos de janelas em telas grandes (como tela dividida e janelas de computador), os desenvolvedores precisam criar apps Android que se adaptem a qualquer tamanho de tela e janela, independentemente da orientação do dispositivo. Paradigmas como restringir a orientação e o redimensionamento são muito restritivos no mundo de vários dispositivos de hoje.

Ignorar restrições de orientação, capacidade de redimensionamento e proporção

Para apps direcionados ao Android 16 (nível 36 da API), o Android 16 inclui mudanças na forma como o sistema gerencia restrições de orientação, capacidade de redimensionamento e proporção. Em telas com largura mínima >= 600 dp, as restrições não se aplicam mais. Os apps também preenchem toda a janela de exibição, independente da proporção ou da orientação preferida do usuário, e não usam o efeito pillarbox.

Essa mudança introduz um novo comportamento padrão da plataforma. O Android está migrando para um modelo em que os apps precisam se adaptar a várias orientações, tamanhos de tela e proporções. Restrições como orientação fixa ou redimensionamento limitado dificultam a adaptabilidade do app. Por isso, recomendamos tornar o app adaptável para oferecer a melhor experiência possível ao usuário.

Você também pode testar esse comportamento usando o framework de compatibilidade de apps e ativando a flag de compatibilidade UNIVERSAL_RESIZABLE_BY_DEFAULT.

Mudanças importantes comuns

Ignorar as restrições de orientação, redimensionamento e proporção pode afetar a interface do seu app em alguns dispositivos, especialmente elementos projetados para layouts pequenos bloqueados na orientação retrato. Por exemplo, problemas como layouts esticados e animações e componentes fora da tela. Qualquer pressuposto sobre proporção ou orientação pode causar problemas visuais no app. Saiba mais sobre como evitar esses problemas e melhorar o comportamento adaptável do app.

Permitir a rotação do dispositivo resulta em mais recriação de atividades, o que pode resultar na perda do estado do usuário se não for preservado adequadamente. Saiba como salvar corretamente o estado da interface em Salvar estados da interface.

Detalhes da implementação

Os seguintes atributos de manifesto e APIs de tempo de execução são ignorados em dispositivos de tela grande nos modos de tela cheia e várias janelas:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

Os seguintes valores para screenOrientation, setRequestedOrientation() e getRequestedOrientation() são ignorados:

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

Em relação ao redimensionamento da tela, android:resizeableActivity="false", android:minAspectRatio e android:maxAspectRatio não têm efeito.

Para apps direcionados ao Android 16 (API de nível 36), as restrições de orientação, redimensionamento e proporção do app são ignoradas por padrão em telas grandes. No entanto, todos os apps que não estão totalmente prontos podem substituir temporariamente esse comportamento desativando a opção, o que resulta no comportamento anterior de ser colocado no modo de compatibilidade.

Exceções

As restrições de orientação, redimensionamento e proporção do Android 16 não se aplicam nas seguintes situações:

• Jogos (com base na flag android:appCategory)
• Os usuários ativarem explicitamente o comportamento padrão do app nas configurações de proporção do dispositivo
• Telas menores que sw600dp

Desativar temporariamente

Para desativar uma atividade específica, declare a propriedade PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY do manifesto:

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

Se muitas partes do seu app não estiverem prontas para o Android 16, você poderá desativar completamente aplicando a mesma propriedade no nível do aplicativo:

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

Saúde e fitness

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

Permissões de saúde e fitness

Para apps direcionados ao Android 16 (API de nível 36) ou mais recente, as permissões BODY_SENSORS usam permissões mais granulares em android.permissions.health, que também são usadas pelo Conexão Saúde. No Android 16, 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ços em primeiro plano:

• HEART_RATE_BPM dos Recursos de saúde no Wear OS
• Sensor.TYPE_HEART_RATE do Android Sensor Manager
• heartRateAccuracy e heartRateBpm do ProtoLayout no Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH em que a permissão android.permission.health respectiva é necessária em vez de BODY_SENSORS

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

• Para monitoramento da frequência cardíaca, SpO₂ ou temperatura da pele durante o uso: solicite a permissão granular em android.permissions.health, como READ_HEART_RATE em vez de BODY_SENSORS.
• Para acesso a sensores em segundo plano, solicite READ_HEALTH_DATA_IN_BACKGROUND em vez de BODY_SENSORS_BACKGROUND.

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 informações de saúde, fitness e bem-estar.

Apps para dispositivos móveis

Os apps para dispositivos móveis que migrarem para usar o 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 do Conexão Saúde.

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.

Novas intents para lidar com perda de vínculo e mudanças na 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.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

Nova maneira de remover a vinculação Bluetooth

Todos os apps destinados ao Android 16 agora podem desvincular dispositivos Bluetooth usando uma API pública em CompanionDeviceManager. Se um dispositivo complementar estiver sendo gerenciado como uma associação de CDM, o app poderá acionar a remoção de pareamento Bluetooth usando a nova API removeBond(int) no dispositivo associado. O app pode monitorar as mudanças de estado de vinculação ouvindo o evento de transmissão do dispositivo Bluetooth ACTION_BOND_STATE_CHANGED.

Segurança

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

Bloqueio de versão do MediaStore

Para apps destinados ao Android 16 ou mais recente, o MediaStore#getVersion() agora será exclusivo para cada app. Isso elimina as propriedades de identificação da string de versão para evitar abuso e uso para técnicas de impressão digital. Os apps não podem fazer suposições sobre o formato dessa versão. Os apps já precisam processar mudanças de versão ao usar essa API e, na maioria dos casos, não precisam mudar o comportamento atual, a menos que o desenvolvedor tenha tentado inferir informações adicionais que estão além do escopo pretendido dessa API.

Intents mais seguras

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Privacidade

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

Permissão de rede local

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

O projeto Local Network Protections visa proteger a privacidade do usuário restringindo o acesso à rede local com uma nova permissão de execução.

Plano de lançamento

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

Impacto

No momento, a portabilidade numérica é um recurso de ativação. Isso significa que apenas os apps que ativarem o recurso 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 possam se preparar para proteger as permissões 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 sockets brutos em endereços de rede local (por exemplo, protocolo de descoberta de serviços 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 exige permissão de acesso à rede local. A tabela a seguir lista alguns casos comuns:

Essas restrições são implementadas na pilha de rede e, portanto, se aplicam a todas as APIs de rede. Isso inclui sockets criados em código nativo ou gerenciado, bibliotecas de rede como Cronet e OkHttp, e todas as APIs implementadas com base nelas. 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 de ou para ele (na porta 53) não exigirá permissão de acesso à rede local.
• Os aplicativos que usam o Output Switcher como seletor no app não vão precisar de permissões de rede local. Mais orientações serão fornecidas no quarto trimestre de 2025.

Orientação 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 Beta 3 do 25Q2 ou mais recente.
2. Instale o app a ser testado.

3. Ative ou desative 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 acessar a 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 permissão para 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 deve ser restaurado, e todos os seus 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.

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

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Erros

Os 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.

Exemplo 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 usa uma interface de rede com capacidade de transmissão, como Wi-Fi ou Ethernet, mas exclui conexões celulares (WWAN) ou VPN.

As seguintes opções 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 (TBD)

Além disso, os 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 local.

Fotos do app

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.