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 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 du mode bord à bord

Android 15 a appliqué le mode bord à bord pour les applications ciblant Android 15 (niveau d'API 35), mais votre application pouvait le désactiver 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 le mode bord à bord.

• 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 dans Android 16, assurez-vous que votre application est compatible avec le mode bord à bord et supprimez toute utilisation de R.attr#windowOptOutEdgeToEdgeEnforcement afin qu'elle soit également compatible avec le mode bord à bord sur un appareil Android 15. Pour prendre en charge le mode bord à bord, consultez les conseils concernant Compose et les vues.

Migration ou désactivation requises pour la prévisualisation du 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 retour en arrière 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 police élégante 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 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 afin d'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 davantage de recréations d'activités, 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'interface utilisateur 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 sont ignorées par défaut sur les grands écrans. Cependant, toute application qui n'est pas entièrement prête peut temporairement annuler ce comportement en le désactivant (ce qui rétablit 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 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 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 la désactiver complètement 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 une version ultérieure, BODY_SENSORS les autorisations 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 correspondante android.permissions.health. 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 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 granulaires respectives :

• Pour la surveillance en cours d'utilisation de la fréquence cardiaque, de la saturation en oxygène ou de la température cutanée : demandez l'autorisation granulaire 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 identiques à celles qui protègent l'accès à la lecture des données de Santé Connect, le magasin de données Android pour les données de santé, de remise en forme et de bien-être.

Applications mobiles

Les applications mobiles qui migrent pour utiliser READ_HEART_RATE et d'autres autorisations granulaires 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 du chiffrement

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

Nouvelle façon de supprimer l'association Bluetooth

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

Sécurité

Android 16 (niveau d'API 36) inclut les modifications de sécurité suivantes.

Verrouillage de la version 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 plus sûrs

La fonctionnalité Intents plus sécurisés est une initiative de sécurité en plusieurs phases conçue pour améliorer la sécurité du mécanisme de résolution d'intent d'Android. L'objectif est de protéger les applications contre les actions malveillantes en ajoutant des vérifications lors du traitement des intents et en filtrant ceux qui ne répondent pas à des critères spécifiques.

Dans Android 15, la fonctionnalité était axée sur l'application émettrice. Désormais, avec Android 16, le contrôle est transféré à l'application réceptrice, ce qui permet aux développeurs d'activer la résolution stricte des intents à l'aide du fichier manifeste de leur application.

Deux modifications clés sont en cours d'implémentation :

1. Les intents explicites doivent correspondre au filtre d'intent du composant cible : si un intent cible explicitement un composant, il doit correspondre au filtre d'intent de ce composant.

2. Les intents sans action ne peuvent correspondre à aucun filtre d'intent : les intents pour lesquels aucune action n'est spécifiée ne doivent pas être résolus en aucun filtre d'intent.

Ces modifications ne s'appliquent que lorsque plusieurs applications sont impliquées et n'affectent pas la gestion des intents dans une seule application.

Impact

Comme il s'agit d'une fonctionnalité à activer, les développeurs doivent l'activer explicitement dans le fichier manifeste de leur application pour qu'elle prenne effet. Par conséquent, l'impact de la fonctionnalité sera limité aux applications dont les développeurs :

• connaissent la fonctionnalité Intents plus sécurisés et ses avantages ;
• choisissent activement d'intégrer des pratiques de gestion des intents plus strictes dans leurs applications.

Cette approche d'activation minimise le risque de rupture des applications existantes qui peuvent s'appuyer sur le comportement actuel de résolution des intents, moins sécurisé.

Bien que l'impact initial dans Android 16 puisse être limité, l'initiative Intents plus sécurisés prévoit un impact plus large dans les futures versions d'Android. L'objectif est de faire de la résolution stricte des intents le comportement par défaut.

La fonctionnalité Intents plus sécurisés a le potentiel d'améliorer considérablement la sécurité de l'écosystème Android en rendant plus difficile l'exploitation des failles du mécanisme de résolution des intents par les applications malveillantes.

Toutefois, la transition vers la désactivation et l'application forcée doit être gérée avec soin pour résoudre les problèmes de compatibilité potentiels avec les applications existantes.

Implémentation

Les développeurs doivent activer explicitement la correspondance plus stricte des intents à l'aide de l'attribut intentMatchingFlags dans le fichier manifeste de leur application. Voici un exemple où la fonctionnalité est activée pour l'ensemble de l'application, mais désactivée/désactivée sur un récepteur :

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

En savoir plus sur les options compatibles :

Tester et déboguer

Lorsque l'application est active, les applications doivent fonctionner correctement si l'appelant de l'intent a correctement rempli l'intent. Toutefois, les intents bloqués déclenchent des messages de journalisation d'avertissement tels que "Intent does not match component's intent filter:" et "Access blocked:" avec la balise "PackageManager." Cela indique un problème potentiel qui pourrait avoir un impact sur l'application et qui nécessite une attention particulière.

Filtre Logcat :

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

Filtrage des appels système du 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.

Cette modification s'applique aux appareils Pixel qui utilisent le GPU Mali (Pixel 6 à 9). Arm a fourni une catégorisation officielle de ses IOCTL dans Documentation/ioctl-categories.rst de sa version r54p2. Cette liste continuera d'être mise à jour dans les futures versions des pilotes.

Cette modification n'a aucune 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 du 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 cette modification :

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 à android-partner-security@google.com.

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 disponibles sur le marché, ou une action de l'utilisateur est-elle requise pour activer une option afin d'appliquer cette modification ? Cette modification s'applique à tous les appareils Pixel disponibles 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 de confidentialité suivantes.

Autorisation d'accès au réseau 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 26Q2 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:

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:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

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

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. 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.

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.

Photos appartenant à l'application

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.