Changements de comportement: applications ciblant Android 16 ou version ultérieure

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 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, quel que soit le 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.

Suppression de l'option de désactivation du mode 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, 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 requises pour la prévisualisation du geste Retour

Pour les applications ciblant Android 16 (niveau d'API 36) ou version ultérieure et s'exécutant sur un appareil Android 16 ou version ultérieure, les animations système de prévisualisation du retour (retour à l'écran d'accueil, multi-activités et multitâches) sont activées par défaut. 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 geste Retour, mettez à jour votre application pour qu'elle utilise les API de navigation Retour compatibles ou désactivez temporairement la prévisualisation 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

Les applications ciblant Android 15 (niveau d'API 35) ont l'attribut elegantTextHeight TextView défini sur true par défaut, ce qui remplace la police compacte par une police beaucoup plus lisible. Vous pouvez remplacer ce comportement en définissant l'attribut elegantTextHeight sur false.

Android 16 abandonne l'attribut elegantTextHeight, qui sera ignoré une fois que votre application ciblera Android 16. Les "UI fonts" contrôlées par ces API sont abandonnées. Vous devez donc adapter toutes les mises en page pour assurer un rendu de texte cohérent et pérenne en arabe, en lao, en birman, en tamoul, en gujarati, en kannada, en malayalam, en odia, en télougou ou en thaï.

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 du travail à taux fixe

Avant de cibler Android 16, lorsque scheduleAtFixedRate manquait une exécution de tâche en raison de l'absence d'un cycle de vie de processus valide, toutes les exécutions manquées s'exécutaient immédiatement lorsque l'application revenait à un cycle de vie valide.

Lorsque vous ciblez Android 16, une seule exécution manquée de scheduleAtFixedRate est immédiatement exécutée lorsque l'application revient à un cycle de vie valide. Ce changement de comportement devrait améliorer les performances de l'application. Testez ce comportement dans votre application pour vérifier si elle est concernée. Vous pouvez également effectuer des tests à l'aide du framework de compatibilité des applications et en activant l'indicateur de compatibilité STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

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

Les applications Android s'exécutent désormais sur une variété d'appareils (téléphones, tablettes, pliables, ordinateurs de bureau, voitures et téléviseurs, par exemple) et de modes de fenêtrage sur les grands écrans (comme le mode écran partagé et le fenêtrage de bureau). Les développeurs doivent donc créer des applications Android qui s'adaptent à toutes les tailles d'écran et de fenêtre, quelle que soit l'orientation de l'appareil. Les paradigmes tels que la restriction de l'orientation et du redimensionnement sont trop restrictifs dans le monde multi-appareils d'aujourd'hui.

Ignorer les restrictions d'orientation, de redimensionnement et de format

Pour les applications ciblant Android 16 (niveau d'API 36), Android 16 inclut des modifications concernant la façon dont le système gère les restrictions d'orientation, de redimensionnement et de format. Les restrictions ne s'appliquent plus aux écrans dont la largeur la plus petite est supérieure ou égale à 600 dp. Les applications remplissent également toute la fenêtre d'affichage, quels que soient le format ou l'orientation préférée de l'utilisateur. Le pillarbox n'est pas utilisé.

Cette modification introduit un nouveau comportement standard de la plate-forme. Android évolue vers un modèle dans lequel les applications sont censées s'adapter à différentes orientations, tailles d'écran et formats. Les restrictions telles que l'orientation fixe ou la redimensionnabilité limitée entravent l'adaptabilité des applications. Nous vous recommandons donc de rendre votre application adaptative pour offrir la meilleure expérience utilisateur possible.

Vous pouvez également tester ce comportement à l'aide du framework de compatibilité des applications et en activant l'indicateur de compatibilité UNIVERSAL_RESIZABLE_BY_DEFAULT.

Modifications destructives courantes

Si vous ignorez les restrictions d'orientation, de redimensionnement et de format, l'UI de votre application peut être affectée sur certains appareils, en particulier les éléments conçus pour de petites mises en page verrouillées en mode Portrait. Par exemple, des problèmes tels que des mises en page étirées, des animations et des composants hors écran peuvent se produire. Toute hypothèse concernant le format ou l'orientation peut entraîner des problèmes visuels dans votre application. En savoir plus sur la façon de les éviter et d'améliorer le comportement adaptatif de votre application

Autoriser la rotation de l'appareil entraîne une recréation plus fréquente de l'activité, ce qui peut entraîner une perte de l'état de l'utilisateur s'il n'est pas correctement conservé. Découvrez comment enregistrer correctement l'état de l'UI dans Enregistrer les états de l'interface utilisateur.

Détails de l'implémentation

Les attributs de fichier manifeste et les API d'exécution suivants sont ignorés sur les appareils à grand écran en mode plein écran et multifenêtre :

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

Les valeurs suivantes pour screenOrientation, setRequestedOrientation() et getRequestedOrientation() sont ignorées :

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

En ce qui concerne le redimensionnement de l'écran, android:resizeableActivity="false", android:minAspectRatio et android:maxAspectRatio n'ont aucun effet.

Pour les applications ciblant Android 16 (niveau d'API 36), les contraintes d'orientation, de redimensionnement et de format de l'application sont ignorées par défaut sur les grands écrans. Toutefois, chaque application qui n'est pas entièrement prête peut temporairement remplacer ce comportement en le désactivant (ce qui entraîne le comportement précédent, à savoir le placement en mode de compatibilité).

Exceptions

Les restrictions d'orientation, de redimensionnement et de format d'Android 16 ne s'appliquent pas dans les situations suivantes :

• Jeux (basés sur le drapeau android:appCategory)
• Les utilisateurs qui activent explicitement le comportement par défaut de l'application dans les paramètres de format de l'appareil
• Écrans dont la taille est inférieure à sw600dp

Désactiver temporairement

Pour désactiver une activité spécifique, déclarez la propriété de fichier manifeste PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY :

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

Si trop de parties de votre application ne sont pas prêtes pour Android 16, vous pouvez désactiver complètement la fonctionnalité en appliquant la même propriété au niveau de l'application :

<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 de 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, que Santé Connect utilise également. Depuis Android 16, toute API qui nécessitait auparavant BODY_SENSORS ou BODY_SENSORS_BACKGROUND requiert à 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 depuis Services Santé sur Wear OS
• Sensor.TYPE_HEART_RATE depuis le gestionnaire de capteurs Android
• heartRateAccuracy et heartRateBpm de ProtoLayout sur Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH où l'autorisation android.permission.health respective est requise à la place de BODY_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 SpO2 ou de la température cutanée pendant l'utilisation : demandez l'autorisation précise sous android.permissions.health, par exemple READ_HEART_RATE au lieu de BODY_SENSORS.
• Pour l'accès aux capteurs en arrière-plan, demandez READ_HEALTH_DATA_IN_BACKGROUND au lieu de BODY_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 dépôt de données 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.

Nouvelles intentions pour gérer la perte de liaison et les modifications du 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'intent ACTION_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 façon de 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ûrs

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:

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

2. 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:

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 suivantes concernant la confidentialité.

Autorisation d'accès au réseau local

Les applications disposant de l'autorisation INTERNET peuvent accéder aux appareils du réseau local. Cela permet aux applications de se connecter facilement aux appareils locaux, mais cela a également des implications en termes de confidentialité, comme la création d'une empreinte digitale de l'utilisateur et le fait d'être un proxy pour la localisation.

Le projet Local Network Protections vise à protéger la confidentialité des utilisateurs en limitant l'accès au réseau local à l'aide d'une nouvelle autorisation d'exécution.

Plan de publication

Ce changement sera déployé entre deux versions, 25Q2 et TBD respectivement. Il est impératif que les développeurs suivent ces conseils pour le deuxième trimestre 2025 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 implicite au réseau local en suivant les conseils ci-dessous et se préparer au refus et à la révocation de la nouvelle autorisation par les utilisateurs.

Impact

À l'heure actuelle, la LNP est une fonctionnalité optionnelle, ce qui signifie que seules les applications qui l'activent seront concernées. L'objectif de la phase d'activation est de permettre aux développeurs d'applications de comprendre quelles parties de leur application dépendent de l'accès implicite au réseau local afin qu'ils puissent se préparer à les protéger par des autorisations 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 via une bibliothèque de sockets bruts sur des adresses de réseau local (par exemple, le 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 depuis une adresse réseau locale nécessite l'autorisation d'accès au réseau local. Le tableau suivant liste quelques cas courants :

Ces restrictions sont implémentées en profondeur dans la pile réseau et s'appliquent donc à toutes les API réseau. Cela inclut les sockets créés dans du code natif ou géré, les bibliothèques réseau telles que Cronet et OkHttp, ainsi que toutes les API implémentées par-dessus. Pour résoudre les services sur le réseau local (c'est-à-dire ceux avec un suffixe .local), vous aurez besoin de l'autorisation du 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é n'auront pas besoin d'autorisations pour le réseau local (plus d'informations seront disponibles au quatrième trimestre 2025).

Conseils pour les développeurs (activation)

Pour activer les restrictions sur le réseau local :

1. Flashez l'appareil avec une version 25Q2 bêta 3 ou ultérieure.
2. Installez l'application à tester.

3. Activez ou désactivez l'indicateur Appcompat dans adb :

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Redémarrez l'appareil.

L'accès de votre application au réseau local est désormais limité. 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 sur le réseau local en dehors du processus de votre 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.

1. Assurez-vous que l'application déclare l'autorisation NEARBY_WIFI_DEVICES dans son fichier manifeste.
2. Accédez à 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.

Voici l'impact sur le trafic réseau des applications une fois que l'application de la protection du réseau local commencera.

Utilisez la commande suivante pour désactiver le flag App-Compat.

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Erreurs

Les erreurs découlant de ces restrictions seront renvoyées au socket appelant chaque fois qu'il invoque l'envoi ou une variante d'envoi à 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 fait référence à un réseau IP qui utilise une interface réseau compatible avec la diffusion, telle que le Wi-Fi ou Ethernet, mais exclut les connexions cellulaires (WWAN) ou VPN.

Les réseaux suivants sont considérés comme des réseaux locaux :

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 :

• Liaison locale
• Routes directement connectées
• Réseaux stub tels que Thread
• Sous-réseaux multiples (à déterminer)

De plus, les adresses de multidiffusion (224.0.0.0/4, ff00::/8) et l'adresse de diffusion IPv4 (255.255.255.255) sont classées comme adresses 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.