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
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 é 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.
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
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
Para apps destinados ao Android 16 (nível 36 da API) ou mais recente,
as permissões BODY_SENSORS
usam permissões mais granulares
em android.permissions.health
, que a Conexão Saúde
também usa. A partir do Android 16, qualquer API que antes exigia BODY_SENSORS
ou BODY_SENSORS_BACKGROUND
agora exige a permissão
android.permissions.health
correspondente. Isso afeta os seguintes tipos
de dados, APIs e serviços em primeiro plano:
HEART_RATE_BPM
dos Recursos de saúde no Wear OSSensor.TYPE_HEART_RATE
do Gerenciador de sensores do AndroidheartRateAccuracy
eheartRateBpm
doProtoLayout
no Wear OSFOREGROUND_SERVICE_TYPE_HEALTH
, em que a permissãoandroid.permission.health
é necessária no lugar deBODY_SENSORS
.
Se o app usar essas APIs, ele precisará solicitar as respectivas permissões granulares:
- Para monitoramento de frequência cardíaca, SpO2 ou temperatura da pele durante o uso:
solicite a permissão granular em
android.permissions.health
, comoREAD_HEART_RATE
em vez deBODY_SENSORS
. - Para acesso a sensores em segundo plano: solicite
READ_HEALTH_DATA_IN_BACKGROUND
em vez deBODY_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 dados de saúde, condicionamento físico 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
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 intentACTION_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 forma 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 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
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:
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.
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:
Flag Name | Description |
---|---|
enforceIntentFilter | Enforces stricter matching for incoming intents |
none | Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the "none" flag |
allowNullAction | Relaxes the matching rules to allow intents without an action to match. This flag to be used in conjunction with "enforceIntentFilter" to achieve a specific behavior |
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 36 da API) 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:
App Low Level Network Operation | Local Network Permission Required |
---|---|
Making an outgoing TCP connection | yes |
Accepting incoming TCP connections | yes |
Sending a UDP unicast, multicast, broadcast | yes |
Receiving an incoming UDP unicast, multicast, broadcast | yes |
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:
- Flash the device to a build with 25Q2 Beta 3 or later.
- Install the app to be tested.
Toggle the Appcompat flag in adb:
adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
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
.
- Ensure the app declares the
NEARBY_WIFI_DEVICES
permission in its manifest. - 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.
Permission | Outbound LAN Request | Outbound/Inbound Internet Request | Inbound LAN Request |
---|---|---|---|
Granted | Works | Works | Works |
Not Granted | Fails | Works | Fails |
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 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.