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

Assim 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 o modo 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, o 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

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

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 (API de nível 36) inclui as seguintes mudanças que modificam ou expandem vários recursos principais do sistema Android.

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

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), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps 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. Make 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:

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

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

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 da 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. 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 esse recurso no manifesto do app para que ele entre em vigor. Como resultado, o impacto do recurso será limitado aos apps em que os desenvolvedores:

• Conhecer o recurso "Objetivos mais seguros" 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 intents menos seguro.

Embora o impacto inicial no Android 16 possa ser limitado, a iniciativa Safer Intents tem um roteiro 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 "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 compatíveis:

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:")

Filtragem de syscalls da GPU

Para reforçar a superfície da GPU Mali, os IOCTLs da GPU Mali que foram descontinuados ou destinados apenas ao desenvolvimento de GPU foram bloqueados em builds de produção. Além disso, as IOCTLs usadas para criação de perfil de GPU foram restritas ao processo do shell ou a aplicativos depuráveis. Consulte a atualização do SAC para mais detalhes sobre a política no nível da plataforma.

Essa mudança ocorre em dispositivos Pixel que usam a GPU Mali (Pixel 6 a 9). A Arm forneceu a categorização oficial dos IOCTLs em Documentation/ioctl-categories.rst da versão r54p2. Essa lista vai continuar sendo atualizada em versões futuras do driver.

Essa mudança não afeta as APIs gráficas compatíveis (incluindo Vulkan e OpenGL) e não deve impactar desenvolvedores ou aplicativos atuais. As ferramentas de criação de perfil da GPU, como o Streamline Performance Analyzer e o Android GPU Inspector, não serão afetadas.

Teste

Se você encontrar uma negação do SELinux semelhante a esta, é provável que seu aplicativo tenha sido afetado por essa mudança:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

Se o aplicativo precisar usar IOCTLs bloqueados, registre um bug e atribua-o a android-partner-security@google.com.

Perguntas frequentes

1. Essa mudança na política se aplica a todos os OEMs? Essa mudança será ativada por opção, mas estará disponível para qualquer OEM que queira usar esse método de proteção. As instruções para implementar a mudança estão na documentação de implementação.

2. É obrigatório fazer mudanças na base de código do OEM para implementar isso, ou o recurso vem com uma nova versão do AOSP por padrão? A mudança no nível da plataforma virá com uma nova versão do AOSP por padrão. Os fornecedores podem ativar essa mudança no codebase se quiserem aplicá-la.

3. Os SoCs são responsáveis por manter a lista de IOCTLs atualizada? Por exemplo, se meu dispositivo usa uma GPU ARM Mali, preciso entrar em contato com a ARM para fazer alguma mudança? Os SoCs individuais precisam atualizar as listas de IOCTL por dispositivo após o lançamento do driver. Por exemplo, a ARM vai atualizar a lista de IOCTLs publicada quando houver atualizações de driver. No entanto, os OEMs precisam incorporar as atualizações na SEPolicy e adicionar os IOCTLs personalizados selecionados às listas, conforme necessário.

4. Essa mudança se aplica automaticamente a todos os dispositivos Pixel à venda ou é necessário que o usuário faça alguma ação para ativar algo e aplicar a mudança? Essa mudança se aplica a todos os dispositivos Pixel no mercado que usam a GPU Mali (Pixel 6 a 9). Nenhuma ação do usuário é necessária para aplicar essa mudança.

5. O uso dessa política afeta o desempenho do driver do kernel? Essa política foi testada na GPU Mali usando o GFXBench, e não foi observada nenhuma mudança mensurável no desempenho da GPU.

6. É necessário que a lista de IOCTLs esteja alinhada com as versões atuais do espaço do usuário e do driver do kernel? Sim, a lista de IOCTLs permitidos precisa ser sincronizada com os IOCTLs compatíveis com os drivers de espaço do usuário e do kernel. Se os IOCTLs no espaço do usuário ou no driver do kernel forem atualizados, a lista de IOCTLs da SEPolicy também precisará ser atualizada para corresponder.

7. A ARM categorizou IOCTLs como "restritas" / "instrumentação", mas queremos usar algumas delas em casos de uso de produção e/ou negar outras. Os OEMs/SoCs individuais são responsáveis por decidir como categorizar os IOCTLs que usam, com base na configuração das bibliotecas Mali do espaço do usuário. A lista da ARM pode ser usada para ajudar a decidir sobre isso, mas o caso de uso de cada OEM/SoC pode ser diferente.

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 26Q2 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.