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 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, peu importe la targetSdkVersion de votre application.

Expérience utilisateur et UI 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 de l'affichage bord à bord

Android 15 applique le mode sans bordures pour les applications ciblant Android 15 (niveau d'API 35), mais votre application peut désactiver cette option en définissant R.attr#windowOptOutEdgeToEdgeEnforcement sur true. Pour les applications ciblant Android 16 (niveau d'API 36), R.attr#windowOptOutEdgeToEdgeEnforcement est obsolète et désactivé, et votre application ne peut pas désactiver l'affichage sans bordure.

• Si votre application cible Android 16 (niveau d'API 36) et s'exécute sur un appareil Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement continue de fonctionner.
• Si votre application cible Android 16 (niveau d'API 36) et s'exécute sur un appareil Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement est désactivé.

Pour effectuer des tests sur Android 16, assurez-vous que votre application est compatible avec le mode sans bordure et supprimez toute utilisation de R.attr#windowOptOutEdgeToEdgeEnforcement afin qu'elle soit également compatible avec le mode sans bordure sur un appareil Android 15. Pour prendre en charge le mode sans bordure, consultez les conseils pour Compose et les vues.

Migration ou désactivation requise 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, multitâche et multi-activité) 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 de retour et que vous n'avez pas encore migré vers la prévisualisation du geste Retour, mettez à jour votre application pour utiliser les API de retour en arrière 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.

Animation de prévisualisation du Retour à l'écran d'accueil

Animation de prévisualisation multi-activités.

Animation prédictive entre les tâches.

API de polices élégantes obsolètes et désactivées

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

elegantTextHeight 行为。

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

elegantTextHeight 行为。

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

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 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 fonctionnant désormais sur une multitude d'appareils (téléphones, tablettes, appareils pliables, ordinateurs de bureau, voitures et téléviseurs, par exemple) et de modes de fenêtrage sur les grands écrans (comme l'écran partagé et le fenêtrage de bureau), les développeurs doivent 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 approches qui limitent l'orientation et le redimensionnement sont trop contraignantes 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), les restrictions d'orientation, de redimensionnement et de format ne s'appliquent plus sur les écrans dont la plus petite largeur est supérieure ou égale à 600 dp. Les applications remplissent toute la fenêtre d'affichage, quels que soient le format ou l'orientation préférés de l'utilisateur, et le format pillarbox n'est pas utilisé.

Cette modification introduit un nouveau comportement standard de la plate-forme. Android évolue vers un modèle où les applications doivent s'adapter à des orientations, tailles d'écran et formats différents. Les restrictions telles que l'orientation fixe ou la taille non modifiable limitent l'adaptabilité des applications. Rendez 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

Ignorer les restrictions d'orientation, de redimensionnement et de format peut avoir un impact sur l'interface utilisateur de votre application sur certains appareils, en particulier sur les éléments conçus pour de petites mises en page verrouillées en mode portrait. Par exemple, cela peut entraîner des problèmes tels que des mises en page étirées, ou des animations et des composants apparaissant hors écran. Toute hypothèse concernant le format ou l'orientation peut entraîner des problèmes visuels dans votre application. Découvrez comment les éviter et 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 la 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 mise en œuvre

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

Concernant la possibilité de redimensionner 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. Chaque application qui n'est pas entièrement prête peut temporairement ignorer ce comportement en désactivant l'option, ce qui entraîne le comportement précédent de 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 l'indicateur android:appCategory)
• Si les utilisateurs activent explicitement le comportement par défaut de l'application dans les paramètres de format de l'appareil
• Écrans inférieurs à 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>

Important : La désactivation est temporaire et ne s'appliquera pas lorsque vous ciblerez le niveau d'API 37 dans une prochaine version d'Android. Autrement dit, pour les applications ciblant le niveau d'API 37, les restrictions d'orientation, de redimensionnement et de format sont ignorées sur les écrans d'au moins sw600dp.

Santé et remise en forme

Android 16 (niveau d'API 36) inclut les modifications suivantes concernant les données de santé et de fitness.

Autorisations liées à la santé et à la 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. À partir d'Android 16, toute API qui nécessitait auparavant BODY_SENSORS ou BODY_SENSORS_BACKGROUND requiert désormais l'autorisation android.permissions.health correspondante. Cela concerne les types de données, les API et les types de services de premier plan suivants :

• HEART_RATE_BPM des Services Santé sur Wear OS
• Sensor.TYPE_HEART_RATE du 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 surveiller la fréquence cardiaque, la SpO2 ou 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 datastore Android pour les données de santé, de fitness et de bien-être.

Applications mobiles

Les applications mobiles qui migrent pour utiliser l'autorisation 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. Cette exigence est la même que pour Santé Connect.

Important : Si vous ne fournissez pas de justification pour les applications mobiles, l'autorisation sera révoquée.

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

Blocage 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

更安全的 intent 功能是一项多阶段安全计划，旨在提高 Android intent 解析机制的安全性。其目标是在 intent 处理期间添加检查并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的影响。

在 Android 15 中，该功能侧重于发送应用。现在，在 Android 16 中，控制权转移到了接收应用，开发者可以使用其应用清单选择启用严格 intent 解析。

我们将实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器相匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器相匹配。

2. 不含操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

由于该功能具有选择启用性质，因此开发者必须在其应用清单中明确启用该功能，它才能生效。 因此，该功能的影响范围仅限于满足以下条件的应用：

• 了解 Safer Intents 功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理做法。

这种选择性启用的方法可最大限度地降低破坏现有应用的风险，这些应用可能依赖于当前安全性较低的 intent 解析行为。

虽然 Android 16 中的初始影响可能有限，但 Safer Intents 计划已制定路线图，将在未来的 Android 版本中产生更广泛的影响。 我们计划最终将严格 intent 解析设为默认行为。

Safer Intents 功能可以提高恶意应用利用 intent 解析机制中的漏洞的难度，从而显著增强 Android 生态系统的安全性。

不过，必须谨慎管理向停用和强制执行的过渡，以解决与现有应用的潜在兼容性问题。

实现

开发者需要在其应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。以下示例展示了如何为整个应用选择启用该功能，但为某个接收器停用/选择退出该功能：

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

注意： 该属性可以在 <application> 标记以及 <activity>、<activity-alias>、<receiver>、<service>、<provider> 等组件标记上指定，并且组件上的属性可用于替换 <application> 标记上的属性

详细了解支持的标志：

标志名称	说明
enforceIntentFilter	对传入 intent 强制执行更严格的匹配
无	停用传入 intent 的所有特殊匹配规则。指定多个标志时，如果值存在冲突，则优先采用“none”标志
allowNullAction	放宽匹配规则，允许不含操作的 intent 进行匹配。此标志将与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

强制执行生效后，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息，例如带有 "PackageManager." 标记的 "Intent does not match component's intent filter:" 和 "Access blocked:"。这表示存在可能影响应用的潜在问题，需要引起注意。

Logcat 过滤条件：

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Filtrage des appels système GPU

Pour renforcer la surface du GPU Mali, les IOCTL du GPU Mali qui ont été abandonnés ou qui sont destinés uniquement au développement du GPU ont été bloqués dans les versions de production. De plus, les IOCTL utilisés pour le profilage du GPU ont été limités au processus shell ou aux applications débogables. Pour en savoir plus sur la stratégie au niveau de la plate-forme, consultez la mise à jour du SAC.

Ce changement s'applique aux appareils Pixel utilisant le GPU Mali (Pixel 6 à 9). Arm a fourni une catégorisation officielle de ses IOCTL dans la Documentation/ioctl-categories.rst de sa version r54p2. Cette liste continuera d'être gérée dans les futures versions du pilote.

Ce changement n'a pas d'incidence sur les API graphiques compatibles (y compris Vulkan et OpenGL) et ne devrait pas avoir d'impact sur les développeurs ni sur les applications existantes. Les outils de profilage de GPU tels que Streamline Performance Analyzer et Android GPU Inspector ne seront pas affectés.

Tests

Si vous voyez un refus SELinux semblable à celui-ci, il est probable que votre application ait été affectée par ce changement :

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

Si votre application doit utiliser des IOCTL bloqués, veuillez signaler un bug et l'attribuer à [e-mail].

Questions fréquentes

1. Cette modification de stratégie s'applique-t-elle à tous les OEM ? Cette modification sera facultative, mais disponible pour tous les OEM qui souhaitent utiliser cette méthode de renforcement. Vous trouverez les instructions pour implémenter la modification dans la documentation sur l'implémentation.

2. Est-il obligatoire d'apporter des modifications au codebase OEM pour implémenter cela, ou est-ce inclus par défaut dans une nouvelle version AOSP ? La modification au niveau de la plate-forme sera fournie par défaut avec une nouvelle version AOSP. Les fournisseurs peuvent choisir d'activer cette modification dans leur codebase s'ils le souhaitent.

3. Les SoC sont-ils responsables de la mise à jour de la liste IOCTL ? Par exemple, si mon appareil utilise un GPU ARM Mali, dois-je contacter ARM pour toute modification ? Les SoC individuels doivent mettre à jour leurs listes IOCTL par appareil lors de la publication des pilotes. Par exemple, ARM actualisera sa liste IOCTL publiée lors des mises à jour des pilotes. Toutefois, les OEM doivent s'assurer d'intégrer les mises à jour dans leur SEPolicy et d'ajouter les IOCTL personnalisés sélectionnés aux listes, si nécessaire.

4. Cette modification s'applique-t-elle automatiquement à tous les appareils Pixel commercialisés ou l'utilisateur doit-il effectuer une action pour l'appliquer ? Cette modification s'applique à tous les appareils Pixel sur le marché qui utilisent le GPU Mali (Pixel 6 à 9). Aucune action de l'utilisateur n'est requise pour appliquer cette modification.

5. L'utilisation de cette stratégie aura-t-elle un impact sur les performances du pilote du kernel ? Cette stratégie a été testée sur le GPU Mali à l'aide de GFXBench, et aucune modification mesurable des performances du GPU n'a été observée.

6. La liste IOCTL doit-elle correspondre aux versions actuelles de l'espace utilisateur et du pilote du kernel ? Oui, la liste des IOCTL autorisés doit être synchronisée avec les IOCTL compatibles avec les pilotes de l'espace utilisateur et du kernel. Si les IOCTL dans l'espace utilisateur ou le pilote du kernel sont mis à jour, la liste des IOCTL SEPolicy doit être mise à jour pour correspondre.

7. ARM a classé les IOCTL comme "restreints"/"instrumentation", mais nous souhaitons en utiliser certains en production et/ou en refuser d'autres. Il incombe à chaque OEM/SoC de décider comment catégoriser les IOCTL qu'ils utilisent, en fonction de la configuration de leurs bibliothèques Mali de l'espace utilisateur. La liste ARM peut vous aider à prendre ces décisions, mais le cas d'utilisation de chaque OEM/SoC peut être différent.

Confidentialité

Android 16 (niveau d'API 36) inclut les modifications suivantes concernant la confidentialité.

Autorisation d'accès au réseau local

Toutes les applis qui disposent de l'autorisation INTERNET peuvent accéder aux appareils du LAN. Cela facilite la connexion des applis aux appareils locaux, mais présente aussi des implications en termes de confidentialité, car cela peut servir à créer une empreinte de l'utilisateur ou à estimer sa position géographique.

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

Ce changement sera déployé entre deux versions, 25Q2 et 26Q2 respectivement. Il est impératif que les développeurs suivent ces consignes pour le deuxième trimestre 2025 et nous fassent part de leurs commentaires, car ces protections seront appliquées dans une prochaine version d'Android. De plus, ils devront mettre à jour les scénarios qui dépendent d'un 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 l'utilisateur.

Impact

À l'heure actuelle, la LNP est une fonctionnalité activable, 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 d'un 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 de :

• Utilisation directe ou via une bibliothèque de sockets bruts sur des adresses réseau locales (par exemple, protocole de découverte 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 certains cas courants :

Opération réseau de bas niveau de l'application	Autorisation d'accès au réseau local requise
Établir une connexion TCP sortante	oui
Accepter les connexions TCP entrantes	oui
Envoi d'une monodiffusion, d'une multidiffusion ou d'une diffusion UDP	oui
Réception d'une monodiffusion, d'une multidiffusion ou d'une diffusion UDP entrante	oui

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. La résolution des services sur le réseau local (c'est-à-dire ceux avec un suffixe .local) nécessite une autorisation d'accès au réseau local.

Remarque : Le trafic provenant des WebViews Android qui nécessitent un accès au réseau local héritera de l'état d'autorisation de l'application hôte.

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 d'accès au réseau local (des conseils supplémentaires seront fournis au quatrième trimestre 2025).

Remarque : De nombreux scénarios de diffusion de contenus multimédias dépendent de l'accès au réseau local et seront affectés par ce changement. Cependant, les applications qui proposent de caster ne devront pas toutes demander la nouvelle autorisation. Les futures API et les conseils pour gérer les scénarios de diffusion seront fournis au quatrième trimestre 2025.

Conseils pour les développeurs (activation requise)

Pour activer les restrictions d'accès au réseau local, procédez comme suit :

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

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

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Redémarrer 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 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 autoriser votre application à 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.

Remarque : Dans une prochaine version d'Android, cette fonctionnalité sera protégée par une nouvelle autorisation dans le groupe d'autorisations "Appareils à proximité".

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 que la protection du réseau local sera appliquée, voici comment le trafic réseau de l'application sera affecté.

Autorisation	Requête LAN sortante	Requête Internet sortante/entrante	Requête LAN entrante
Accordé	YouTube	YouTube	YouTube
Refusée	Gags	YouTube	Gags

Utilisez la commande suivante pour désactiver l'option 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 appellera send ou une variante de send 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, comme le Wi-Fi ou Ethernet, mais exclut les connexions cellulaires (WWAN) ou les connexions 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 comme Thread
• Plusieurs sous-réseaux (à déterminer)

De plus, les adresses multicast (224.0.0.0/4, ff00::/8) et l'adresse de broadcast IPv4 (255.255.255.255) sont classées comme des adresses réseau locales.

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.