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
O Android 15 forçou a tela de ponta a ponta para apps direcionados ao Android 15 (nível
35 da API), mas seu app pode desativar essa configuração definindo
R.attr#windowOptOutEdgeToEdgeEnforcement
como true
. Para apps
direcionados ao Android 16 (nível 36 da API),
R.attr#windowOptOutEdgeToEdgeEnforcement
foi descontinuado e desativado, e o
app não pode desativar a exibição de borda a borda.
- Se o app for destinado ao Android 16 (nível 36 da API) e estiver sendo executado em um
dispositivo com o Android 15, o
R.attr#windowOptOutEdgeToEdgeEnforcement
vai continuar funcionando. - Se o app for destinado ao Android 16 (nível 36 da API) e estiver sendo executado em um
dispositivo com o Android 16, o
R.attr#windowOptOutEdgeToEdgeEnforcement
será desativado.
Para testar no Android 16 Beta 3, verifique se o app oferece suporte a tela de ponta a ponta e
remova qualquer uso de R.attr#windowOptOutEdgeToEdgeEnforcement
para que ele
também ofereça suporte a tela de ponta a ponta em um dispositivo Android 15. Para oferecer suporte a tela cheia,
consulte as orientações de Compose e Views.
Migração ou desativação necessária 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 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.

elegantTextHeight
para apps direcionados ao Android
14 (nível 34 da API) e versões anteriores ou para apps direcionados ao Android 15 (nível 35 da API)
que substituem o padrão definindo o atributo elegantTextHeight
como false
.
elegantTextHeight
para apps destinados ao Android
16 ou para apps destinados ao Android 15 (nível 35 da API) que não substituíram o
padrão definindo o atributo elegantTextHeight
como
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
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 receivingACTION_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 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
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:
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.
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:
Nome da flag | Descrição |
---|---|
enforceIntentFilter | Aplica uma correspondência mais rigorosa para intents recebidas |
none | Desativa todas as regras de correspondência especial para intents recebidas. Ao especificar várias flags, os valores conflitantes são resolvidos dando precedência à flag "none". |
allowNullAction | Relaxa as regras de correspondência para permitir intents sem uma ação correspondente. Essa flag precisa ser usada com "enforceIntentFilter" para alcançar um comportamento específico. |
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
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
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.