Modifications de comportement : applications ciblant Android 12

Comme les versions précédentes, Android 12 apporte des modifications de comportement pouvant affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 12 ou version ultérieure. Si votre application cible Android 12, 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 12.

Expérience utilisateur

Notifications personnalisées

Android 12 modifie l'apparence et le comportement des notifications entièrement personnalisées. Auparavant, les notifications personnalisées pouvaient utiliser l'intégralité de la zone de notification, et fournir leurs propres mises en page et styles. Cela a entraîné des anti-modèles qui pourraient dérouter les utilisateurs ou entraîner des problèmes de compatibilité de mise en page sur différents appareils.

Pour les applications ciblant Android 12, les notifications avec des vues de contenu personnalisées n'utilisent plus la zone de notification complète. Le système applique à la place un modèle standard. Ce modèle garantit que les notifications personnalisées ont la même décoration que les autres notifications, quel que soit leur état, comme l'icône de notification et les affordances d'expansion (à l'état réduit), ainsi que l'icône de notification, le nom de l'application et l' affordance de réduction (à l'état d'expansion). Ce comportement est presque identique à celui de Notification.DecoratedCustomViewStyle.

De cette manière, Android 12 rend toutes les notifications visuellement cohérentes et faciles à parcourir, avec une extension des notifications visible et familière pour les utilisateurs.

L'illustration suivante montre une notification personnalisée dans le modèle standard :

Les exemples suivants montrent comment les notifications personnalisées s'affichent dans un état réduit et développé:

Le changement d'Android 12 affecte les applications qui définissent des sous-classes personnalisées de Notification.Style, ou qui utilisent les méthodes de Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) et setCustomHeadsUpContentView(RemoteViews).

Si votre application utilise des notifications entièrement personnalisées, nous vous recommandons de la tester dès que possible avec le nouveau modèle.

1. Activez le changement de notifications personnalisées :

   1. Remplacez targetSdkVersion par S dans votre application pour activer le nouveau comportement.
   2. Recompilez.
   3. Installez votre application sur un appareil ou un émulateur exécutant Android 12.

2. Testez toutes les notifications qui utilisent des vues personnalisées pour vous assurer qu'elles ont l'apparence attendue dans l'ombre. Lors du test, tenez compte des éléments suivants et effectuez les ajustements nécessaires:

   • Les dimensions des vues personnalisées ont changé. En général, la hauteur des notifications personnalisées est inférieure à celle d'avant. À l'état réduit, la hauteur maximale du contenu personnalisé est passée de 106 dp à 48 dp. De plus, l'espace horizontal est moins important.

   • Toutes les notifications peuvent être développées pour les applications ciblant Android 12. En règle générale, si vous utilisez setCustomContentView, vous devez également utiliser setBigCustomContentView pour vous assurer que les états développés et réduits sont cohérents.

   • Pour vous assurer que l'état "Avertissement" s'affiche comme prévu, n'oubliez pas de définir l'importance du canal de notification sur "ÉLEVÉE" (s'affiche à l'écran).

Modifications apportées à la validation d'Android App Links

Pour les applications qui ciblent Android 12 ou version ultérieure, le système apporte plusieurs modifications à la méthode de validation des liens d'application Android. Ces modifications améliorent la fiabilité de l'expérience d'association d'applications et offrent plus de contrôle aux développeurs d'applications et aux utilisateurs finaux.

Si vous vous appuyez sur la validation Android App Link pour ouvrir des liens Web dans votre application, vérifiez que vous utilisez le bon format lorsque vous ajoutez des filtres d'intent pour la validation Android App Link. Assurez-vous en particulier que ces filtres d'intent incluent la catégorie BROWSABLE et qu'ils sont compatibles avec le schéma https.

Vous pouvez également vérifier manuellement les liens de votre application pour tester la fiabilité de vos déclarations.

Amélioration du comportement de la fonctionnalité Picture-in-picture

Android 12 apporte des améliorations de comportement pour le mode Picture-in-picture (PIP) et des améliorations esthétiques recommandées pour les animations de transition pour la navigation par gestes et la navigation basée sur des éléments.

Pour en savoir plus, consultez la section Améliorations de la fonctionnalité Picture-in-picture.

Refonte des toasts

Dans Android 12, la vue toast a été repensée. Les toasts sont désormais limités à deux lignes de texte et affichent l'icône de l'application à côté du texte.

Pour en savoir plus, consultez la section Présentation des toasts.

Sécurité et confidentialité

Position approximative

Sur les appareils équipés d'Android 12 ou version ultérieure, les utilisateurs peuvent demander une précision de position approximative pour votre application.

Remarque :Dans certaines versions d'Android 12, cette modification affecte toujours votre application, quelle que soit la version du SDK cible.

Cookies modernes SameSite dans WebView

Le composant WebView d'Android est basé sur Chromium, le projet Open Source sur lequel repose le navigateur Chrome de Google. Chromium a apporté des modifications à la gestion des cookies tiers pour renforcer la sécurité et la confidentialité, et offrir aux utilisateurs plus de transparence et de contrôle. À partir d'Android 12, ces modifications sont également incluses dans WebView lorsque les applications ciblent Android 12 (niveau d'API 31) ou version ultérieure.

L'attribut SameSite d'un cookie détermine s'il peut être envoyé avec des requêtes ou uniquement avec des requêtes de même site. Les modifications de protection de la confidentialité suivantes améliorent la gestion par défaut des cookies tiers et aident à protéger contre le partage intersites involontaire:

• Les cookies sans attribut SameSite sont traités comme SameSite=Lax.
• Les cookies avec SameSite=None doivent également spécifier l'attribut Secure, ce qui signifie qu'ils nécessitent un contexte sécurisé et doivent être envoyés via HTTPS.
• Les liens entre les versions HTTP et HTTPS d'un site sont désormais traités comme des requêtes intersites. Les cookies ne sont donc pas envoyés, sauf s'ils sont correctement marqués comme SameSite=None; Secure.

Pour les développeurs, il est recommandé d'identifier les dépendances des cookies intersites dans vos flux utilisateur critiques et de s'assurer que l'attribut SameSite est défini explicitement avec les valeurs appropriées si nécessaire. Vous devez spécifier explicitement les cookies autorisés à fonctionner sur les sites Web ou dans les navigations sur un même site qui passent du HTTP au HTTPS.

Pour obtenir des conseils complets sur ces modifications destinées aux développeurs Web, consultez les pages SameSite Cookies Explained et Schemeful SameSite.

Tester les comportements SameSite dans votre application

Si votre application utilise WebView, ou si vous gérez un site Web ou un service qui utilise des cookies, nous vous recommandons de tester vos flux sur Android 12 WebView. Si vous rencontrez des problèmes, vous devrez peut-être mettre à jour vos cookies pour qu'ils prennent en charge les nouveaux comportements de SameSite.

Recherchez les problèmes liés aux connexions et au contenu intégré, ainsi qu'aux flux de connexion, d'achat et d'autres flux d'authentification où l'utilisateur commence sur une page non sécurisée et passe à une page sécurisée.

Pour tester une application avec WebView, vous devez activer les nouveaux comportements SameSite pour l'application que vous souhaitez tester en procédant de l'une des façons suivantes:

• Activez manuellement les comportements SameSite sur l'appareil de test en activant ou désactivant l'indicateur d'interface utilisateur webview-enable-modern-cookie-same-site dans les outils de développement WebView.

  Cette approche vous permet de tester sur n'importe quel appareil équipé d'Android 5.0 (niveau d'API 21) ou version ultérieure (y compris Android 12) et de WebView version 89.0.4385.0 ou ultérieure.

• Compilez votre application pour cibler Android 12 (niveau d'API 31) d'ici le targetSdkVersion.

  Si vous utilisez cette approche, vous devez utiliser un appareil équipé d'Android 12.

Pour en savoir plus sur le débogage à distance pour WebView sur Android, consultez Premiers pas avec le débogage à distance des appareils Android.

Autres ressources

Pour en savoir plus sur les comportements modernes de SameSite et sur leur déploiement dans Chrome et WebView, consultez la page Chromium SameSite Updates. Si vous trouvez un bug dans WebView ou Chromium, vous pouvez le signaler dans l'outil public de suivi des problèmes Chromium.

Les capteurs de mouvement sont limités en débit

Pour protéger les informations potentiellement sensibles sur les utilisateurs, si votre application cible Android 12 ou version ultérieure, le système limite la fréquence d'actualisation des données provenant de certains capteurs de mouvement et de position.

En savoir plus sur la limitation de la fréquence d'échantillonnage des capteurs

Hibernation des applications

Android 12 développe le comportement de réinitialisation automatique des autorisations introduit dans Android 11 (niveau d'API 30). Si votre application cible Android 12 et que l'utilisateur n'interagit pas avec elle pendant quelques mois, le système réinitialise automatiquement toutes les autorisations accordées et place votre application en hibernation.

Pour en savoir plus, consultez le guide sur la hibernation des applications.

Déclaration d'attribution dans l'audit des accès aux données

L'API d'audit des accès aux données, introduite dans Android 11 (niveau d'API 30), vous permet de créer des balises d'attribution en fonction des cas d'utilisation de votre application. Ces balises vous permettent de déterminer plus facilement quelle partie de votre application effectue un type d'accès aux données spécifique.

Si votre application cible Android 12 ou une version ultérieure, vous devez déclarer ces balises d'attribution dans le fichier manifeste de votre application.

Restriction de sauvegarde ADB

Pour contribuer à la protection des données d'application privées, Android 12 modifie le comportement par défaut de la commande adb backup. Pour les applications qui ciblent Android 12 (niveau d'API 31) ou version ultérieure, lorsqu'un utilisateur exécute la commande adb backup, les données de l'application sont exclues de toutes les autres données système exportées depuis l'appareil.

Si vos workflows de test ou de développement reposent sur des données d'application à l'aide de adb backup, vous pouvez désormais activer l'exportation des données de votre application en définissant android:debuggable sur true dans le fichier manifeste de votre application.

Attention : Pour protéger les données de votre application, n'oubliez pas de définir android:debuggable sur false avant de la publier.

Exportation de composants plus sécurisée

Si votre application cible Android 12 ou une version ultérieure et contient des activités, des services ou des broadcast receivers qui utilisent des filtres d'intent, vous devez déclarer explicitement l'attribut android:exported pour ces composants d'application.

Avertissement : Si une activité, un service ou un broadcast receiver utilise des filtres d'intent et n'a pas de valeur déclarée explicitement pour android:exported, votre application ne peut pas être installée sur un appareil exécutant Android 12 ou une version ultérieure.

Si le composant de l'application inclut la catégorie LAUNCHER, définissez android:exported sur true. Dans la plupart des autres cas, définissez android:exported sur false.

L'extrait de code suivant montre un exemple de service contenant un filtre d'intent dont l'attribut android:exported est défini sur false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Messages dans Android Studio

Si votre application contient une activité, un service ou un broadcast receiver qui utilise des filtres d'intent, mais ne déclare pas android:exported, les messages d'avertissement suivants s'affichent, en fonction de la version d'Android Studio que vous utilisez:

Android Studio 2020.3.1 Canary 11 ou version ultérieure

Les messages suivants s'affichent :

1. L'avertissement lint suivant s'affiche dans votre fichier manifeste:

   When using intent filters, please specify android:exported as well
   

2. Lorsque vous tentez de compiler votre application, le message d'erreur de compilation suivant s'affiche:

   Manifest merger failed : Apps targeting Android 12 and higher are required \
   to specify an explicit value for android:exported when the corresponding \
   component has an intent filter defined.
   

Versions antérieures d'Android Studio

Si vous tentez d'installer l'application, Logcat affiche le message d'erreur suivant :

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Mutabilité des intents en attente

Si votre application cible Android 12, vous devez spécifier la mutabilité de chaque objet PendingIntent créé par votre application. Cette exigence supplémentaire améliore la sécurité de votre application.

Tester la modification de mutabilité de l'intent en attente

Pour déterminer si des déclarations de mutabilité sont manquantes dans votre application, recherchez l'avertissement lint suivant dans Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Lancements d'intents non sécurisés

Pour améliorer la sécurité de la plate-forme, Android 12 et les versions ultérieures proposent une fonctionnalité de débogage qui détecte les lancements d'intents non sécurisés. Lorsque le système détecte un tel lancement non sécurisé, une violation du mode strict se produit.

Performances

Restrictions de lancement des services de premier plan

Les applications qui ciblent Android 12 ou version ultérieure ne peuvent pas démarrer de services de premier plan lorsqu'elles s'exécutent en arrière-plan, sauf dans quelques cas particuliers. Si une application tente de démarrer un service de premier plan pendant l'exécution en arrière-plan, une exception se produit (sauf dans les quelques cas particuliers mentionnés).

Envisagez d'utiliser WorkManager pour planifier et commencer des tâches prioritaires pendant que votre application s'exécute en arrière-plan. Pour effectuer des actions urgentes demandées par l'utilisateur, démarrez les services de premier plan dans une alarme exacte.

Autorisation "Alarme exacte"

Pour encourager les applications à économiser les ressources système, celles qui ciblent Android 12 ou version ultérieure et définissent des alarmes exactes doivent avoir accès à la fonctionnalité "Alarmes et rappels" qui s'affiche sur l'écran Accès spécifiques des applications dans les paramètres système.

Pour obtenir cet accès spécial à l'application, demandez l'autorisation SCHEDULE_EXACT_ALARM dans le fichier manifeste.

Les alarmes exactes ne doivent être utilisées que pour les fonctionnalités destinées aux utilisateurs. En savoir plus sur les cas d'utilisation acceptables pour définir une alarme exacte

Désactiver le changement de comportement

Lorsque vous préparez votre application à cibler Android 12, vous pouvez désactiver temporairement le changement de comportement dans votre variante de compilation débogable à des fins de test. Pour ce faire, procédez comme suit:

• Sur l'écran des paramètres Developer options (Options pour les développeurs), sélectionnez App Compatibility Changes (Modifications de la compatibilité de l'application). Sur l'écran qui s'affiche, appuyez sur le nom de votre application, puis désactivez REQUIRE_EXACT_ALARM_PERMISSION.

• Dans une fenêtre de terminal de votre ordinateur de développement, exécutez la commande suivante:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

Restrictions liées aux trampolines de notification

Lorsque les utilisateurs interagissent avec des notifications, certaines applications répondent aux pressions sur les notifications en lançant un composant d'application qui lance finalement l'activité que l'utilisateur voit et avec laquelle il interagit. Ce composant d'application est appelé trampoline de notification.

Pour améliorer leurs performances et l'expérience utilisateur, les applications qui ciblent Android 12 ou une version ultérieure ne peuvent pas démarrer d'activités à partir de services ni de broadcast receivers utilisés comme trampolines de notification. En d'autres termes, lorsqu'un utilisateur appuie sur une notification ou sur un bouton d'action dans une notification, votre application ne peut pas appeler startActivity() au sein d'un service ou d'un broadcast receiver.

Lorsque votre application tente de démarrer une activité à partir d'un service ou d'un broadcast receiver qui agit comme un trampoline de notification, le système empêche le démarrage de l'activité et le message suivant s'affiche dans Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Remarque :Bien que les applications disposant de l'autorisation SYSTEM_ALERT_WINDOW puissent toujours démarrer des activités à l'aide d'un trampoline de notification, vous devez éviter ce modèle d'expérience utilisateur et utiliser un PendingIntent à la place.

Identifier les composants d'application qui servent de trampolines de notification

Lorsque vous testez votre application, après avoir appuyé sur une notification, vous pouvez identifier le service ou le broadcast receiver qui a servi de trampoline de notification dans votre application. Pour ce faire, examinez la sortie de la commande de terminal suivante :

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Une section de la sortie inclut le texte "NotifInteractionLog". Cette section contient les informations nécessaires pour identifier le composant qui démarre après un appui sur une notification.

Mettre à jour votre appli

Si votre application démarre une activité à partir d'un service ou d'un broadcast receiver qui agit comme un trampoline de notification, procédez comme suit:

1. Créez un objet PendingIntent associé à l'activité que les utilisateurs voient après avoir appuyé sur la notification.
2. Utilisez l'objet PendingIntent que vous avez créé à l'étape précédente pour créer votre notification.

Pour identifier l'origine de l'activité, par exemple pour effectuer une journalisation, utilisez des extras lors de la publication de la notification. Pour la journalisation centralisée, utilisez ActivityLifecycleCallbacks ou les observateurs de cycle de vie Jetpack.

Activer/Désactiver le comportement

Lorsque vous testez une version débogable de votre application, vous pouvez activer et désactiver cette restriction à l'aide de l'indicateur de compatibilité de l'application NOTIFICATION_TRAMPOLINE_BLOCK.

Sauvegarder et restaurer

Le fonctionnement de la sauvegarde et de la restauration a été modifié dans les applications exécutées sur Android 12 (niveau d'API 31) et ciblant cette version. La sauvegarde et la restauration Android se présentent sous deux formes:

• Sauvegardes cloud:les données utilisateur sont stockées dans le Google Drive d'un utilisateur afin de pouvoir être restaurées ultérieurement sur cet appareil ou sur un nouvel appareil.
• Transferts d'appareil à appareil (D2D):les données utilisateur sont envoyées directement vers le nouvel appareil de l'utilisateur depuis son ancien appareil, par exemple à l'aide d'un câble.

Pour en savoir plus sur la sauvegarde et la restauration des données, consultez les sections Sauvegarder les données utilisateur avec la sauvegarde automatique et Sauvegarder des paires clé-valeur avec Android Backup Service.

Modifications apportées à la fonctionnalité de transfert D2D

Pour les applications exécutées sur Android 12 ou version ultérieure et ciblant cette version :

• Spécifier des règles d'inclusion et d'exclusion avec le mécanisme de configuration XML n'a aucune incidence sur les transferts D2D, mais affecte toujours la sauvegarde et la restauration dans le cloud (telles que les sauvegardes Google Drive). Pour spécifier des règles pour les transferts D2D, vous devez utiliser la nouvelle configuration décrite dans la section suivante.

• Sur les appareils de certains fabricants, spécifier android:allowBackup="false" désactive les sauvegardes sur Google Drive, mais ne désactive pas les transferts D2D pour l'application.

Nouveau format d'inclusion et d'exclusion

Les applications exécutées sur Android 12 ou version ultérieure et ciblant cette version utilisent un format différent pour la configuration XML. Ce format fait la distinction explicite entre la sauvegarde Google Drive et le transfert D2D en vous obligeant à spécifier des règles d'inclusion et d'exclusion séparément pour les sauvegardes dans le cloud et pour le transfert D2D.

Vous pouvez également l'utiliser pour spécifier des règles de sauvegarde, auquel cas la configuration précédemment utilisée est ignorée sur les appareils exécutant Android 12 ou version ultérieure. L'ancienne configuration est toujours requise pour les appareils équipés d'Android 11 ou version antérieure.

Remarque : Si vous utilisez le nouveau format de configuration, votre application utilisera le nouveau comportement lorsqu'elle s'exécute sur un appareil équipé d'Android 12 ou version ultérieure, même si vous ne ciblez pas encore Android 12.

Modifications du format XML

Voici le format utilisé pour la configuration de la sauvegarde et de la restauration dans Android 11 ou version antérieure:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Les modifications apportées au format sont indiquées en gras ci-dessous.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Pour en savoir plus, consultez la section correspondante du guide de sauvegarde des données utilisateur avec la sauvegarde automatique.

Indicateur de fichier manifeste pour les applications

Faites pointer vos applications vers la nouvelle configuration XML à l'aide de l'attribut android:dataExtractionRules dans votre fichier manifeste. Lorsque vous pointez vers la nouvelle configuration XML, l'attribut android:fullBackupContent qui pointe vers l'ancienne configuration est ignoré sur les appareils équipés d'Android 12 ou version ultérieure. L'exemple de code suivant montre les nouvelles entrées de fichier manifeste:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Connectivité

Autorisations Bluetooth

Android 12 introduit les autorisations BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE et BLUETOOTH_CONNECT. Ces autorisations permettent aux applications qui ciblent Android 12 de communiquer plus facilement avec les appareils Bluetooth, en particulier pour les applications qui n'ont pas besoin d'accéder à la position de l'appareil.

Pour préparer votre appareil au ciblage d'Android 12 ou version ultérieure, mettez à jour la logique de votre application. Au lieu de déclarer un ancien ensemble d'autorisations Bluetooth, déclarez un ensemble d'autorisations Bluetooth plus moderne.

Connexion Internet et peer-to-peer simultanées

Pour les applications ciblant Android 12 (niveau d'API 31) ou version ultérieure, les appareils compatibles avec les connexions peer-to-peer et Internet simultanées peuvent maintenir des connexions Wi-Fi simultanées à la fois à l'appareil pair et au réseau Internet principal, ce qui rend l'expérience utilisateur plus fluide. Les applications ciblant Android 11 (niveau d'API 30) ou version antérieure présentent toujours l'ancien comportement, où le réseau Wi-Fi principal est déconnecté avant de se connecter à l'appareil homologue.

Compatibilité

WifiManager.getConnectionInfo() ne peut renvoyer le WifiInfo que pour un seul réseau. Par conséquent, le comportement de l'API a été modifié de la manière suivante dans Android 12 et versions ultérieures:

• Si un seul réseau Wi-Fi est disponible, son WifiInfo est renvoyé.
• Si plusieurs réseaux Wi-Fi sont disponibles et que l'application appelante a déclenché une connexion point à point, l'WifiInfo correspondant à l'appareil homologue est renvoyé.
• Si plusieurs réseaux Wi-Fi sont disponibles et que l'application appelante n'a pas déclenché de connexion point à point, la WifiInfo de la connexion Internet principale est renvoyée.

Pour offrir une meilleure expérience utilisateur sur les appareils compatibles avec deux réseaux Wi-Fi simultanés, nous recommandons à toutes les applications, en particulier celles qui déclenchent des connexions peer-to-peer, de ne plus appeler WifiManager.getConnectionInfo() et d'utiliser plutôt NetworkCallback.onCapabilitiesChanged() pour obtenir tous les objets WifiInfo correspondant à l'NetworkRequest utilisé pour enregistrer NetworkCallback. getConnectionInfo() est obsolète depuis Android 12.

L'exemple de code suivant montre comment obtenir WifiInfo dans un NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

API native mDNSResponder

Android 12 change lorsque les applications peuvent interagir avec le daemon mDNSResponder à l'aide de l'API native mDNSResponder. Auparavant, lorsqu'une application enregistrait un service sur le réseau et appelait la méthode getSystemService(), le service NSD du système démarrait le daemon mDNSResponder, même si l'application n'avait pas encore appelé de méthodes NsdManager. Le daemon a ensuite abonné l'appareil aux groupes de multidiffusion tous les nœuds, ce qui amène le système à s'activer plus fréquemment et à utiliser une puissance supplémentaire. Pour réduire la consommation de la batterie, sous Android 12 et versions ultérieures, le système ne démarre désormais le daemon mDNSResponder que lorsqu'il est nécessaire pour les événements NSD et l'arrête ensuite.

Étant donné que cette modification affecte le moment où le daemon mDNSRépondreer est disponible, les applications qui supposent que le daemon mDNSRépondreer est démarré après avoir appelé la méthode getSystemService() peuvent recevoir des messages du système indiquant que le daemon mDNSRépondreer n'est pas disponible. Les applications qui utilisent NsdManager et qui n'utilisent pas l'API native mDNSRépondreer ne sont pas concernées par ce changement.

Bibliothèques de fournisseurs

Bibliothèques partagées natives fournies par le fournisseur

Les bibliothèques partagées natives non NDK fournies par les fournisseurs ou les fabricants d'appareils ne sont pas accessibles par défaut si l'application cible Android 12 (niveau d'API 31) ou une version ultérieure. Les bibliothèques ne sont accessibles que lorsqu'elles sont explicitement demandées à l'aide de la balise <uses-native-library>.

Si l'application cible Android 11 (niveau d'API 30) ou une version antérieure, la balise <uses-native-library> n'est pas obligatoire. Dans ce cas, n'importe quelle bibliothèque partagée native est accessible, qu'il s'agisse d'une bibliothèque du NDK ou non.

Mise à jour des restrictions non SDK

Android 12 inclut des listes à jour d'interfaces non SDK limitées grâce à la collaboration avec les développeurs Android et aux derniers tests internes. Dans la mesure du possible, nous nous assurons que des alternatives publiques sont disponibles avant de limiter les interfaces non SDK.

Si votre application ne cible pas Android 12, certaines de ces modifications ne vous affecteront peut-être pas immédiatement. Cependant, bien que vous puissiez actuellement utiliser certaines interfaces non SDK (en fonction du niveau d'API cible de votre application), l'utilisation d'un champ ou d'une méthode non SDK présente toujours un risque élevé d'endommager votre application.

Si vous n'êtes pas sûr que votre application utilise des interfaces non SDK, vous pouvez tester votre application pour le savoir. Si votre application repose sur des interfaces non SDK, vous devriez commencer à planifier une migration vers des alternatives SDK. Nous comprenons néanmoins que certaines applications ont des cas d'utilisation valides pour utiliser des interfaces non SDK. Si vous ne trouvez pas d'alternative à l'utilisation d'une interface non SDK pour une fonctionnalité de votre application, vous devriez demander une nouvelle API publique.

Pour en savoir plus sur les modifications apportées à cette version d'Android, consultez Mises à jour des restrictions d'interface non SDK dans Android 12. Pour en savoir plus sur les interfaces non SDK en général, consultez la section Restrictions concernant les interfaces non SDK.