Comme les versions précédentes, Android 16 apporte des modifications de comportement pouvant affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 16 ou version ultérieure. Si votre application cible Android 16 ou une version ultérieure, vous devez la modifier pour qu'elle prenne en charge ces comportements, le cas échéant.
Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications exécutées sur Android 16, quelle que soit la targetSdkVersion
de votre application.
Expérience utilisateur et interface utilisateur du système
Android 16 (niveau d'API 36) inclut les modifications suivantes, qui visent à créer une expérience utilisateur plus cohérente et intuitive.
Fin de la possibilité de désactiver l'affichage bord à bord
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.
Migration ou désactivation requise pour la prévisualisation du Retour
Pour les applications ciblant Android 16 (niveau d'API 36) ou version ultérieure et exécutées sur un appareil Android 16 ou version ultérieure, les animations système de prévisualisation du Retour sont activées par défaut (retour à l'écran d'accueil, multi-tâche et multi-activité).
De plus, onBackPressed
n'est pas appelé et KeyEvent.KEYCODE_BACK
n'est plus distribué.
Si votre application intercepte l'événement "Retour" et que vous n'avez pas encore migré vers la prévisualisation du Retour, mettez à jour votre application pour qu'elle utilise les API de navigation "Retour" compatibles ou désactivez temporairement cette fonctionnalité en définissant l'attribut android:enableOnBackInvokedCallback
sur false
dans la balise <application>
ou <activity>
du fichier AndroidManifest.xml
de votre application.
API de polices élégantes obsolètes et désactivées
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
.Fonctionnalité de base
Android 16 (niveau d'API 36) inclut les modifications suivantes qui modifient ou étendent diverses fonctionnalités de base du système Android.
Optimisation de la planification des tâches à tarif fixe
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.
Facteurs de forme des appareils
Android 16 (niveau d'API 36) inclut les modifications suivantes pour les applications lorsqu'elles sont affichées sur des appareils à grand écran.
Mises en page adaptatives
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), Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply. Apps also 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, so we recommend making 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>
Santé et remise en forme
Android 16 (niveau d'API 36) inclut les modifications suivantes concernant les données de santé et de remise en forme.
Autorisations de santé et remise en forme
Pour les applications ciblant Android 16 (niveau d'API 36) ou version ultérieure, les autorisations BODY_SENSORS
utilisent des autorisations plus précises sous android.permissions.health
, qui sont également utilisées par Santé Connect. À partir d'Android 16, toute API qui nécessitait auparavant BODY_SENSORS
ou BODY_SENSORS_BACKGROUND
nécessite à la place l'autorisation android.permissions.health
correspondante. Cela affecte les types de données, les API et les types de services de premier plan suivants:
HEART_RATE_BPM
de Services Santé sur Wear OSSensor.TYPE_HEART_RATE
à partir du Gestionnaire de capteurs AndroidheartRateAccuracy
etheartRateBpm
à partir deProtoLayout
sur Wear OSFOREGROUND_SERVICE_TYPE_HEALTH
, où l'autorisationandroid.permission.health
correspondante est requise à la place deBODY_SENSORS
Si votre application utilise ces API, elle doit demander les autorisations précises correspondantes:
- Pour la surveillance de la fréquence cardiaque, de la saturation en oxygène ou de la température cutanée pendant l'utilisation : demandez l'autorisation précise sous
android.permissions.health
, par exempleREAD_HEART_RATE
au lieu deBODY_SENSORS
. - Pour l'accès aux capteurs en arrière-plan, demandez
READ_HEALTH_DATA_IN_BACKGROUND
au lieu deBODY_SENSORS_BACKGROUND
.
Ces autorisations sont les mêmes que celles qui protègent l'accès à la lecture des données de Santé Connect, le datastore Android pour les données de santé, de remise en forme et de bien-être.
Dans les applications mobiles
Les applications mobiles qui migrent vers l'utilisation de READ_HEART_RATE
et d'autres autorisations précises doivent également déclarer une activité pour afficher les règles de confidentialité de l'application. Il s'agit de la même exigence que pour Santé Connect.
Connectivité
Android 16 (niveau d'API 36) inclut les modifications suivantes dans la pile Bluetooth pour améliorer la connectivité avec les périphériques.
Nouveaux intents pour gérer la perte de liaison et les modifications de chiffrement
Dans le cadre de la gestion améliorée de la perte de liaison, Android 16 introduit également deux nouveaux intents pour mieux informer les applications de la perte de liaison et des modifications de chiffrement.
Les applications ciblant Android 16 peuvent désormais:
- Recevoir un intent
ACTION_KEY_MISSING
lorsqu'une perte de liaison à distance est détectée, ce qui leur permet de fournir des commentaires plus informatifs sur l'utilisateur et de prendre les mesures appropriées. - Recevoir un intent
ACTION_ENCRYPTION_CHANGE
chaque fois que l'état du chiffrement du lien change. Cela inclut la modification de l'état du chiffrement, de l'algorithme de chiffrement et de la taille de la clé de chiffrement. Les applications doivent considérer que l'association est restaurée si le lien est correctement chiffré lors de la réception de l'intentACTION_ENCRYPTION_CHANGE
ultérieurement.
S'adapter aux implémentations OEM variées
Bien qu'Android 16 introduise ces nouveaux intents, leur implémentation et leur diffusion peuvent varier selon les fabricants d'appareils (OEM). Pour que votre application offre une expérience cohérente et fiable sur tous les appareils, les développeurs doivent concevoir leur gestion des pertes de liaison pour s'adapter de manière appropriée à ces variations potentielles.
Nous vous recommandons les comportements d'application suivants:
Si l'intent
ACTION_KEY_MISSING
est diffusé:Le lien ACL (Asynchronous Connection-Less) sera déconnecté par le système, mais les informations de liaison de l'appareil seront conservées (comme décrit ici).
Votre application doit utiliser cet intent comme signal principal pour la détection de la perte de liaison et guider l'utilisateur pour qu'il confirme que l'appareil distant est à portée avant de lancer l'oubli de l'appareil ou le réassociation.
Si un appareil se déconnecte après la réception de
ACTION_KEY_MISSING
, votre application doit être prudente lors de la reconnexion, car l'appareil peut ne plus être associé au système.Si l'intent
ACTION_KEY_MISSING
n'est PAS diffusé:Le lien ACL restera connecté, et les informations d'association de l'appareil seront supprimées par le système, comme dans Android 15.
Dans ce scénario, votre application doit poursuivre ses mécanismes de gestion des pertes de liaison existants, comme dans les versions précédentes d'Android, pour détecter et gérer les événements de perte de liaison.
Nouvelle méthode pour supprimer l'association Bluetooth
Toutes les applications ciblant Android 16 peuvent désormais dissocier des appareils Bluetooth à l'aide d'une API publique dans CompanionDeviceManager
. Si un appareil associé est géré en tant qu'association CDM, l'application peut déclencher la suppression de l'association Bluetooth à l'aide de la nouvelle API removeBond(int)
sur l'appareil associé. L'application peut surveiller les changements d'état de l'association en écoutant l'événement de diffusion de l'appareil Bluetooth ACTION_BOND_STATE_CHANGED
.
Sécurité
Android 16 (niveau d'API 36) inclut les modifications de sécurité suivantes.
Verrouillage de la version MediaStore
Pour les applications ciblant Android 16 ou version ultérieure, MediaStore#getVersion()
sera désormais unique pour chaque application. Cela élimine les propriétés d'identification de la chaîne de version pour éviter les utilisations abusives et l'utilisation de techniques d'empreinte digitale. Les applications ne doivent pas faire d'hypothèses sur le format de cette version. Les applications doivent déjà gérer les modifications de version lorsqu'elles utilisent cette API et, dans la plupart des cas, elles ne doivent pas avoir besoin de modifier leur comportement actuel, sauf si le développeur a tenté d'inférer des informations supplémentaires qui dépassent le champ d'application prévu de cette API.
Intents plus sécurisés
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:")
Confidentialité
Android 16 (niveau d'API 36) inclut les modifications de confidentialité suivantes.
Autorisation d'accès au réseau local
Les appareils du LAN peuvent être accessibles par n'importe quelle application disposant de l'autorisation INTERNET
.
Cela permet aux applications de se connecter facilement aux appareils locaux, mais cela a également des implications en termes de confidentialité, telles que la création d'une empreinte de l'utilisateur et le fait d'être un proxy pour la position.
Le projet de protection du réseau local vise à protéger la confidentialité de l'utilisateur en limitant l'accès au réseau local derrière une nouvelle autorisation d'exécution.
Plan de publication
Cette modification sera déployée entre deux versions, 25Q2 et TBD respectivement. Il est impératif que les développeurs suivent ces consignes pour 25Q2 et partagent leurs commentaires, car ces protections seront appliquées dans une version ultérieure d'Android. De plus, ils devront mettre à jour les scénarios qui dépendent de l'accès réseau local implicite en suivant les conseils ci-dessous et se préparer au refus de l'utilisateur et à la révocation de la nouvelle autorisation.
Impact
Pour le moment, la fonctionnalité LNP est disponible sur inscription, ce qui signifie que seules les applications qui l'activent seront concernées. L'objectif de la phase d'activation est que les développeurs d'applications comprennent quelles parties de leur application dépendent de l'accès au réseau local implicite afin de pouvoir les protéger par autorisation pour la prochaine version.
Les applications seront affectées si elles accèdent au réseau local de l'utilisateur à l'aide des éléments suivants:
- Utilisation directe ou par bibliothèque de sockets bruts sur des adresses réseau locales (par exemple, protocole de détection de services mDNS ou SSDP)
- Utilisation de classes au niveau du framework qui accèdent au réseau local (par exemple, NsdManager)
Le trafic vers et à partir d'une adresse réseau locale nécessite une autorisation d'accès au réseau local. Le tableau suivant présente quelques cas courants:
Opérations réseau de bas niveau de l'application | Autorisation du réseau local requise |
---|---|
Établir une connexion TCP sortante | oui |
Accepter les connexions TCP entrantes | oui |
Envoyer une diffusion UDP, une diffusion unicast ou une diffusion multicast | oui |
Recevoir une diffusion, une multidiffusion ou un unicast UDP entrant | oui |
Ces restrictions sont implémentées profondément dans la pile réseau et s'appliquent donc à toutes les API réseau. Cela inclut les sockets créés en code natif ou géré, les bibliothèques réseau telles que Cronet et OkHttp, ainsi que les API implémentées sur ces éléments. Essayer de résoudre des services sur le réseau local (c'est-à-dire ceux avec un suffixe .local) nécessite une autorisation de réseau local.
Exceptions aux règles ci-dessus:
- Si le serveur DNS d'un appareil se trouve sur un réseau local, le trafic vers ou depuis celui-ci (sur le port 53) ne nécessite pas d'autorisation d'accès au réseau local.
- Les applications qui utilisent le sélecteur de sortie comme sélecteur intégré à l'application n'auront pas besoin d'autorisations de réseau local (plus d'informations à venir au 4e trimestre 2025).
Conseils pour les développeurs (activation)
Pour activer les restrictions de réseau local, procédez comme suit:
- Flashez l'appareil avec une version 25Q2 bêta 3 ou ultérieure.
- Installez l'application à tester.
Activez/désactivez l'indicateur Appcompat dans adb:
adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
Redémarrez l'appareil.
L'accès de votre application au réseau local est désormais limité, et toute tentative d'accès au réseau local entraînera des erreurs de socket. Si vous utilisez des API qui effectuent des opérations réseau locales en dehors de votre processus d'application (par exemple, NsdManager), elles ne seront pas affectées pendant la phase d'activation.
Pour restaurer l'accès, vous devez accorder à votre application l'autorisation NEARBY_WIFI_DEVICES
.
- Assurez-vous que l'application déclare l'autorisation
NEARBY_WIFI_DEVICES
dans son fichier manifeste. - Accédez à Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow (Paramètres > Applications > [Nom de l'application] > Autorisations > Appareils à proximité > Autoriser).
L'accès de votre application au réseau local devrait maintenant être rétabli, et tous vos scénarios devraient fonctionner comme avant l'activation de l'application.
Une fois l'application de la protection du réseau local lancée, voici l'impact sur le trafic réseau de l'application.
Autorisation | Requête LAN sortante | Requête Internet sortante/entrante | Requête LAN entrante |
---|---|---|---|
Accordé | Works | Works | Works |
Refusé | Gags | Works | Gags |
Utilisez la commande suivante pour désactiver l'indicateur App-Compat
adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>
Erreurs
Les erreurs découlant de ces restrictions sont renvoyées au socket appelant chaque fois qu'il appelle send ou une variante d'envoi vers une adresse réseau locale.
Exemples d'erreurs:
sendto failed: EPERM (Operation not permitted)
sendto failed: ECONNABORTED (Operation not permitted)
Définition du réseau local
Dans ce projet, un réseau local désigne un réseau IP qui utilise une interface réseau compatible avec la diffusion, telle que le Wi-Fi ou l'Ethernet, mais qui exclut les connexions mobiles (WWAN) ou VPN.
Les réseaux suivants sont considérés comme des réseaux locaux:
IPv4 :
- 169.254.0.0/16 // Liaison locale
- 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 :
- Lien local
- Routes directement connectées
- Réseaux de bouchons tels que Thread
- Plusieurs sous-réseaux (à déterminer)
De plus, les adresses multicast (224.0.0.0/4, ff00::/8) et l'adresse de diffusion IPv4 (255.255.255.255) sont classées comme adresses de réseau local.
Photos appartenant à l'application
Lorsqu'une application ciblant le SDK 36 ou version ultérieure sur des appareils équipés d'Android 16 ou version ultérieure demande des autorisations de photo et de vidéo, les utilisateurs qui choisissent de limiter l'accès aux contenus multimédias sélectionnés verront les photos appartenant à l'application présélectionnées dans le sélecteur de photos. Les utilisateurs peuvent désélectionner n'importe lequel de ces éléments présélectionnés, ce qui révoque l'accès de l'application à ces photos et vidéos.