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 toute la zone de notification et fournir leurs propres mises en page et styles. Cela a entraîné des antipatrons 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 l'état. Par exemple, l'icône et les affordances d'expansion de la notification (à l'état réduit), ainsi que l'icône, le nom de l'application et l'affordance de réduction de la notification (à l'état développé). Ce comportement est presque identique à celui de Notification.DecoratedCustomViewStyle.

Android 12 rend ainsi toutes les notifications visuellement cohérentes et faciles à parcourir, avec une expansion des notifications reconnaissable 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 lorsqu'elles sont réduites et développées :

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

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

  1. Activez la modification des 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 et assurez-vous qu'elles s'affichent comme prévu dans la barre de notifications. Lors des tests, tenez compte des points suivants et apportez les ajustements nécessaires :

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

    • Toutes les notifications sont développables 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 réduit et développé sont cohérents.

    • Pour vous assurer que l'état "Heads Up" s'affiche comme prévu, n'oubliez pas de définir l'importance du canal de notification sur "HIGH" (Pop-up à l'écran).

Sur les applications qui ciblent Android 12 ou version ultérieure, le système apporte plusieurs modifications à la façon dont les liens d'application Android sont validés. 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 des Android App Links 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 des Android App Links. En particulier, assurez-vous que ces filtres d'intent incluent la catégorie BROWSABLE et prennent en charge le schéma https.

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

Améliorations du comportement du Picture-in-picture

Android 12 améliore le comportement du mode Picture-in-picture (PIP) et recommande des améliorations esthétiques pour les animations de transition, à la fois pour la navigation par gestes et la navigation par éléments.

Pour en savoir plus, consultez Améliorations du mode Picture-in-picture.

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

Image d'un appareil Android affichant un toast dans une fenêtre pop-up indiquant "Sending message…" (Envoi du message) à côté d'une icône d'application

Pour en savoir plus, consultez 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 approximative de la position pour votre application.

Cookies SameSite modernes dans WebView

Le composant WebView d'Android est basé sur Chromium, le projet Open Source qui alimente le navigateur Chrome de Google. Chromium a modifié 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 n'importe quelle requête ou uniquement avec des requêtes ciblant un même site. Les modifications suivantes, qui protègent la confidentialité, améliorent la gestion par défaut des cookies tiers et aident à se protéger contre le partage involontaire entre sites :

  • 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 multisites. Par conséquent, les cookies ne sont pas envoyés, sauf s'ils sont correctement marqués comme SameSite=None; Secure.

Pour les développeurs, la recommandation générale consiste à identifier les dépendances des cookies multisites dans vos flux utilisateur critiques et à 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 plusieurs sites Web ou lors de navigations sur le même site qui passent de HTTP à HTTPS.

Pour obtenir des instructions complètes sur ces modifications destinées aux développeurs Web, consultez Présentation des cookies SameSite et SameSite avec schéma.

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 soient compatibles avec les nouveaux comportements SameSite.

Recherchez les problèmes de connexion et de contenu intégré, ainsi que les 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 manières suivantes :

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 le déploiement dans Chrome et WebView, consultez la page Mises à jour Chromium SameSite. 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 soumis à une limite de 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 de certains capteurs de mouvement et de position.

En savoir plus sur la limitation du débit 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 l'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 tags 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 version ultérieure, vous devez déclarer ces balises d'attribution dans le fichier manifeste de votre application.

Restriction de sauvegarde ADB

Pour protéger les données privées des applications, Android 12 modifie le comportement par défaut de la commande adb backup. Pour les applications ciblant 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 s'appuient sur les données d'application à l'aide de adb backup, vous pouvez désormais choisir d'exporter les données de votre application en définissant android:debuggable sur true dans le fichier manifeste de votre application.

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.

Si le composant d'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, selon 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.
Anciennes versions 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 PendingIntents

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

Tester la modification de la mutabilité des intents en attente

Pour déterminer si votre application ne comporte pas de déclarations de mutabilité, recherchez l'avertissement lint suivant dans Android Studio :

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Lancement d'intents non sécurisés

Pour améliorer la sécurité de la plate-forme, Android 12 et les versions ultérieures fournissent 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 StrictMode se produit.

Performances

Restrictions de lancement des services de premier plan

Les applications ciblant 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 qui 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 régler une alarme exacte

Désactiver le changement de comportement

Lorsque vous préparez votre application à cibler Android 12, vous pouvez désactiver temporairement la modification du 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 Options pour les développeurs, sélectionnez 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 les notifications, certaines applications répondent aux appuis sur les notifications en lançant un composant d'application qui finit par démarrer l'activité que l'utilisateur voit et avec laquelle il interagit. Ce composant d'application est appelé trampoline de notification.

Pour améliorer les performances et l'expérience utilisateur des applications, celles 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 sert de 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.

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 agi comme trampoline de notification dans votre application. Pour ce faire, consultez 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 à la suite d'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 sert de trampoline de notification, suivez les étapes de migration suivantes :

  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é, afin d'effectuer la journalisation par exemple, utilisez des extras lorsque vous publiez 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 changé dans les applications qui s'exécutent sur Android 12 (niveau d'API 31) et qui ciblent cette version. La sauvegarde et la restauration Android se présentent sous deux formes :

  • Sauvegardes dans le 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 Sauvegarder les données utilisateur avec la sauvegarde automatique et Sauvegarder des paires clé-valeur avec Android Backup Service.

Modifications des fonctionnalités de transfert D2D

Pour les applications s'exécutant 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'affecte pas les transferts D2D, mais affecte toujours la sauvegarde et la restauration basées sur le cloud (comme 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, la spécification de android:allowBackup="false" désactive les sauvegardes sur Google Drive, mais pas les transferts D2D pour l'application.

Nouveau format d'inclusion et d'exclusion

Les applications s'exécutant sur Android 12 ou version ultérieure et ciblant ces versions utilisent un format différent pour la configuration XML. Ce format permet de faire explicitement la différence entre la sauvegarde Google Drive et le transfert D2D en vous demandant de spécifier des règles d'inclusion et d'exclusion distinctes pour les sauvegardes cloud et pour le transfert D2D.

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

Modifications du format XML

Voici le format utilisé pour la configuration de la sauvegarde et de la restauration dans Android 11 et versions antérieures :

<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 sur la sauvegarde des données utilisateur avec la sauvegarde automatique.

Indicateur de fichier manifeste pour les applications

Pointez 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 exécutant Android 12 ou version ultérieure. L'exemple de code suivant montre les nouvelles entrées du 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 ciblant Android 12 d'interagir plus facilement avec les appareils Bluetooth, en particulier celles qui n'ont pas besoin d'accéder à la position de l'appareil.

Pour préparer votre appareil à cibler 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 simultanées peer-to-peer et Internet peuvent maintenir des connexions Wi-Fi simultanées à l'appareil pair et au réseau principal fournissant Internet, ce qui rend l'expérience utilisateur plus fluide. Les applications ciblant Android 11 (niveau d'API 30) ou version antérieure continuent de bénéficier de l'ancien comportement, où le réseau Wi-Fi principal est déconnecté avant la connexion à l'appareil pair.

Compatibilité

WifiManager.getConnectionInfo() ne peut renvoyer 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 d'appel a déclenché une connexion peer-to-peer, le WifiInfo correspondant à l'appareil pair est renvoyé.
  • Si plusieurs réseaux Wi-Fi sont disponibles et que l'application d'appel n'a pas déclenché de connexion peer-to-peer, le WifiInfo de la connexion principale fournissant Internet est renvoyé.

Pour offrir une meilleure expérience utilisateur sur les appareils compatibles avec les réseaux Wi-Fi doubles 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 à NetworkRequest utilisé pour enregistrer NetworkCallback. getConnectionInfo() est obsolète depuis Android 12.

L'exemple de code suivant montre comment obtenir le 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 modifie les conditions dans lesquelles les applications peuvent interagir avec le démon 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 démon mDNSResponder, même si l'application n'avait pas encore appelé de méthodes NsdManager. Le démon a ensuite abonné l'appareil aux groupes multicast de tous les nœuds, ce qui a entraîné un réveil plus fréquent du système et une consommation d'énergie supplémentaire. Pour minimiser l'utilisation de la batterie, dans Android 12 et versions ultérieures, le système ne démarre le démon mDNSResponder que lorsqu'il est nécessaire pour les événements NSD, puis l'arrête par la suite.

Étant donné que cette modification affecte le moment où le daemon mDNSResponder est disponible, les applications qui supposent que le daemon mDNSResponder sera démarré après l'appel de la méthode getSystemService() peuvent recevoir des messages du système indiquant que le daemon mDNSResponder n'est pas disponible. Les applications qui utilisent NsdManager et n'utilisent pas l'API native mDNSResponder 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 ne faisant pas partie du NDK et distribuées 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 Restrictions concernant les interfaces non SDK.