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 versões mais recentes. 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 será removida

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 Beta 3, 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ária para a volta preditiva

对于以 Android 16（API 级别 36）或更高版本为目标平台且在 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不会调用 onBackPressed，也不会再调度 KeyEvent.KEYCODE_BACK。

如果您的应用拦截了返回事件，并且您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API；或者，在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false，以暂时停用此功能。

APIs de fonte elegante 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, e ele será ignorado quando o app for destinado ao Android 16. As "fontes de IU" controladas por essas APIs estão sendo descontinuadas. Portanto, adapte todos os layouts para garantir a renderização consistente e futura de texto em árabe, lao, myanmar, tâmil, gujarati, canará, malaiala, ódia, télugo ou tailandês.

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

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

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

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

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

Para apps destinados 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, redimensionamento e proporção. Em telas com largura mínima de 600 dp, as restrições não mais se aplicam. Os apps também preenchem toda a janela de exibição, independentemente da proporção ou da orientação preferida do usuário, e o pillarboxing não é usado.

Essa mudança introduz um novo comportamento padrão da plataforma. O Android está se movendo 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.

Também é possível testar esse comportamento usando o framework de compatibilidade do app e ativando a flag de compatibilidade UNIVERSAL_RESIZABLE_BY_DEFAULT.

Mudanças interruptivas comuns

Ignorar as restrições de orientação, redimensionamento e proporção pode afetar a interface do app em alguns dispositivos, principalmente 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 suposição sobre a proporção ou orientação pode causar problemas visuais no app. Saiba mais sobre como evitar esses problemas e melhorar o comportamento adaptativo 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 corretamente. Saiba como salvar corretamente o estado da interface em Salvar estados da interface.

Detalhes da implementação

Os atributos de manifesto e as APIs de execução a seguir são ignorados em dispositivos de tela grande nos modos de tela cheia e de 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 à capacidade de redimensionamento da tela, android:resizeableActivity="false", android:minAspectRatio e android:maxAspectRatio não têm efeito.

Para apps direcionados ao Android 16 (nível 36 da API), a orientação do app, o redimensionamento e as restrições de proporção são ignoradas em telas grandes por padrão, mas todos os apps que não estão totalmente prontos podem substituir temporariamente esse comportamento desativando essa 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 ativam 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 de manifesto PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

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

Se muitas partes do 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 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

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用，BODY_SENSORS 权限会使用 android.permissions.health 下的更精细权限，Health Connect 也会使用这些权限。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• Wear OS 上的健康服务中的 HEART_RATE_BPM
• Android Sensor Manager 中的 Sensor.TYPE_HEART_RATE
• Wear OS 上 ProtoLayout 中的 heartRateAccuracy 和 heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH，其中需要使用相应的 android.permission.health 权限来替代 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 如需在使用期间监测心率、血氧饱和度或体表温度：请在 android.permissions.health 下请求精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 对于后台传感器访问权限：请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与用于保护对 Health Connect（用于存储健康、健身和身心健康数据的 Android 数据存储区）读取数据的权限相同。

移动应用

迁移到使用 READ_HEART_RATE 和其他精细权限的移动应用还必须声明 activity 以显示应用的隐私权政策。这与 Health Connect 的要求相同。

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

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

Nova forma de remover a vinculação Bluetooth

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

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.

Intents mais seguras

O recurso Safer Intents é uma iniciativa de segurança em várias fases projetada para melhorar a segurança do mecanismo de resolução de intents do Android. O objetivo é proteger os apps de 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 focado no app de envio, agora com o Android 16, transfere o controle para o app de recebimento, permitindo que os desenvolvedores ativem a resolução de intent rígida 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 explicita tem como destino 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 podem ser resolvidas em 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

A natureza de ativação significa que os desenvolvedores precisam ativá-la explicitamente no manifesto do app para que ela entre em vigor. Como resultado, o impacto do recurso será limitado aos apps em que os desenvolvedores:

• Conhecer o recurso Safer Intents e os benefícios dele.
• Escolher incorporar práticas de processamento de intents mais rígidas nos apps.

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

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

O recurso Safer Intents 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 desativação e a aplicação obrigatória precisam ser gerenciadas com cuidado para resolver possíveis problemas de compatibilidade com apps existentes.

Implementação

Os desenvolvedores precisam ativar explicitamente a correspondência de intent mais rígida usando o atributo intentMatchingFlags no manifesto do app. Confira um exemplo em que o recurso está 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 autor da chamada 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 requer 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 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:

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

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 (TBD)

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.

Fotos de propriedade 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.