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

O Android 15 impôs o modo de ponta a ponta para apps direcionados ao Android 15 (nível 35 da API), mas seu app pode desativar essa opção definindo R.attr#windowOptOutEdgeToEdgeEnforcement como true. Em apps direcionados ao Android 16 (nível 36 da API), R.attr#windowOptOutEdgeToEdgeEnforcement está descontinuado e desativado, e seu app não pode desativar a exibição de ponta a ponta.

• Se o app for destinado ao Android 16 (nível 36 da API) e estiver sendo executado em um dispositivo 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 Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement será desativado.

Para testar no Android 16, verifique se o app é compatível com o modo de ponta a ponta e remova qualquer uso de R.attr#windowOptOutEdgeToEdgeEnforcement para que o app também seja compatível com o modo de ponta a ponta em um dispositivo Android 15. Para oferecer suporte de ponta a ponta, consulte as orientações do Compose e do Views.

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 a volta preditiva, atualize o app para usar as APIs de navegação de retorno 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 da 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 restrição de orientação e redimensionamento são muito restritivos no mundo multitelas 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 recentes, 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 vinculação e mudanças na criptografia

Como parte do Processamento de perda de vínculo aprimorado, o Android 16 também apresenta duas novas intents para dar aos apps mais consciência da perda de vínculo e mudanças de criptografia.

Os apps destinados ao Android 16 agora podem:

• Receber uma intent ACTION_KEY_MISSING quando a perda de vínculo remoto é detectada, permitindo que eles forneçam feedback mais informativo ao usuário e realizem ações adequadas.
• Receba uma intent ACTION_ENCRYPTION_CHANGE sempre que o status de criptografia do link mudar. Isso inclui a mudança de status de criptografia, de algoritmo de criptografia e de tamanho da chave de criptografia. Os apps precisam considerar a vinculação restaurada se o link for criptografado ao receber a intent ACTION_ENCRYPTION_CHANGE mais tarde.

Como se adaptar a diferentes implementações de OEM

Embora o Android 16 apresente essas novas intents, a implementação e a transmissão delas podem variar de acordo com os diferentes fabricantes de dispositivos (OEMs). Para garantir que o app ofereça uma experiência consistente e confiável em todos os dispositivos, os desenvolvedores precisam projetar o processamento de perda de vínculo para se adaptar a essas variações.

Recomendamos os seguintes comportamentos do app:

• Se a intent ACTION_KEY_MISSING for transmitida:

  O link ACL (Asynchronous Connection-Less) será desconectado pelo sistema, mas as informações de vinculação do dispositivo serão mantidas, conforme descrito aqui.

  Seu app precisa usar essa intent como o indicador principal para a detecção de perda de conexão e orientar o usuário a confirmar se o dispositivo remoto está no alcance antes de iniciar o esquecimento ou o novo pareamento do dispositivo.

  Se um dispositivo se desconectar depois que o ACTION_KEY_MISSING for recebido, o app precisará ter cuidado ao se reconectar, porque o dispositivo pode não estar mais vinculado ao sistema.

• Se a intent ACTION_KEY_MISSING NÃO for transmitida:

  O link ACL vai permanecer conectado, e as informações de vinculação do dispositivo serão removidas pelo sistema, assim como no comportamento do Android 15.

  Nesse cenário, o app precisa continuar com os mecanismos de processamento de perda de vínculo existentes, como nas versões anteriores do Android, para detectar e gerenciar eventos de perda de vínculo.

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

O recurso Safer Intents é uma iniciativa de segurança multifásica projetada para melhorar a segurança do mecanismo de resolução de intents do Android. O objetivo é proteger os apps contra ações maliciosas adicionando verificações durante o processamento de intents e filtrando intents que não atendem a critérios específicos.

No Android 15, o recurso se concentrava no app de envio. Agora, com o Android 16, o controle é transferido para o app de recebimento, permitindo que os desenvolvedores ativem a resolução estrita de intents usando o manifesto do app.

Duas mudanças importantes estão sendo implementadas:

1. As intents explícitas precisam corresponder ao filtro de intent do componente de destino: se uma intent segmenta explicitamente um componente, ela precisa corresponder ao filtro de intent desse componente.

2. Intents sem uma ação não podem corresponder a nenhum filtro de intent: intents que não têm uma ação especificada não devem ser resolvidas para nenhum filtro de intent.

Essas mudanças só se aplicam quando vários apps estão envolvidos e não afetam o processamento de intents em um único app.

Impacto

Como a ativação é opcional, os desenvolvedores precisam habilitar explicitamente o recurso no manifesto do app para que ele entre em vigor. Como resultado, o impacto do recurso será limitado aos apps cujos desenvolvedores:

• Conhecer o recurso "Intenções mais seguras" e os benefícios dele.
• Escolher ativamente incorporar práticas mais rigorosas de processamento de intents nos apps.

Essa abordagem de ativação minimiza o risco de quebrar apps atuais que podem depender do comportamento de resolução de intent menos seguro.

Embora o impacto inicial no Android 16 possa ser limitado, a iniciativa Safer Intents tem um plano para um impacto mais amplo em versões futuras do Android. O plano é tornar a resolução estrita de intents o comportamento padrão.

O recurso de intents mais seguras tem o potencial de melhorar significativamente a segurança do ecossistema Android, dificultando que apps maliciosos explorem vulnerabilidades no mecanismo de resolução de intents.

No entanto, a transição para a recusa e a restrição obrigatória precisam ser gerenciadas com cuidado para resolver possíveis problemas de compatibilidade com apps atuais.

Implementação

Os desenvolvedores precisam ativar explicitamente a correspondência de intents mais restrita usando o atributo intentMatchingFlags no manifesto do app. Confira um exemplo em que o recurso é ativado para todo o app, mas desativado/desativado em um receptor:

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

Mais sobre as flags aceitas:

Teste e depuração

Quando a aplicação estiver ativa, os apps vão funcionar corretamente se o chamador de intent tiver preenchido a intent corretamente. No entanto, intents bloqueadas vão acionar mensagens de registro de aviso, como "Intent does not match component's intent filter:" e "Access blocked:" com a tag "PackageManager." Isso indica um possível problema que pode afetar o app e exige atenção.

Filtro do Logcat:

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

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and TBD respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

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
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

Fotos do app

Quando um app destinado ao SDK 36 ou mais recente solicitar permissões de fotos e vídeos em dispositivos com o Android 16 ou versões mais recentes, os usuários que optarem por limitar o acesso à mídia selecionada vão encontrar as fotos pertencentes ao app pré-selecionadas no seletor de fotos. Os usuários podem desmarcar qualquer um desses itens pré-selecionados, o que revoga o acesso do app a essas fotos e vídeos.