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 susceptibles de perturber les utilisateurs ou de causer 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, comme l'icône de la notification et les affordances d'expansion (à l'état réduit), ainsi que l'icône de la notification, le nom de l'application et l'affordance de réduction (à l'état développé). Ce comportement est presque identique à celui de Notification.DecoratedCustomViewStyle.

Ainsi, Android 12 rend toutes les notifications visuellement cohérentes et faciles à parcourir, avec une extension de notification familière et facile à découvrir 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 à l'état réduit et développé :

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 setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) et setCustomHeadsUpContentView(RemoteViews) de Notification.Builder.

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

  1. Activez la modification des notifications personnalisées :

    1. Remplacez le targetSdkVersion de votre application par S 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, en vous assurant qu'elles s'affichent comme prévu dans l'ombre. Lors des tests, tenez compte des points suivants et effectuez 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 d'auparavant. À 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 restreint.

    • Toutes les notifications sont extensibles pour les applications ciblant Android 12. En règle générale, cela signifie que 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" (S'affiche à l'écran).

Sur les applications qui ciblent Android 12 ou version ultérieure, le système apporte plusieurs modifications à la méthode de validation d'Android App Links. 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 utilisez la validation des liens vers une application Android 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 liens vers une application Android. En particulier, assurez-vous que ces filtres d'intent incluent la catégorie BROWSABLE et acceptent 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 apporte des améliorations au comportement du mode Picture-in-picture (PIP) et des améliorations esthétiques recommandées aux animations de transition pour la navigation par gestes et la navigation basée sur des éléments.

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

Refonte des notifications toast

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 de localisation approximative 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 les requêtes SameSite. 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 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. 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, il est généralement conseillé d'identifier les dépendances des cookies intersites dans vos parcours utilisateur critiques et de vous assurer que l'attribut SameSite est explicitement défini avec les valeurs appropriées, si nécessaire. Vous devez spécifier explicitement les cookies autorisés à fonctionner sur plusieurs sites ou sur des navigations sur un même site qui passent de HTTP à HTTPS.

Pour obtenir des conseils complets sur ces modifications destinés aux développeurs Web, consultez Présentation des cookies SameSite 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 WebView Android 12. Si vous rencontrez des problèmes, vous devrez peut-être mettre à jour vos cookies pour qu'ils soient compatibles avec les nouveaux comportements SameSite.

Surveillez 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 effectuant l'une des opérations suivantes :

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

Autres ressources

Pour en savoir plus sur les comportements modernes de SameSite et leur déploiement sur Chrome et WebView, consultez la page Mises à jour de SameSite sur Chromium. 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 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 d'annulation 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 tags 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 la sauvegarde ADB

Pour protéger les données de l'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 s'appuient sur les 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.

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 essayez 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 intents en attente

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é 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 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 de StrictMode 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 à préserver les ressources système, les applications 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 visibles par l'utilisateur. 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 la modification de comportement dans votre variante de compilation débogable à des fins de test. Pour ce faire, effectuez l'une des tâches suivantes :

  • 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 démarre 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 de l'application 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 ou 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 agissent comme des 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 en tant que trampoline de notification dans votre application. Pour ce faire, examinez le résultat 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.

Mettez à jour votre application

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

  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é d'application NOTIFICATION_TRAMPOLINE_BLOCK.

Sauvegarde et restauration

Le fonctionnement de la sauvegarde et de la restauration a été modifié pour les applications exécutées sous 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 de l'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 de l'ancien appareil de l'utilisateur vers son nouvel 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 exécutées sur Android 12 et versions ultérieures et ciblant ces versions :

  • Spécifier des règles d'inclusion et d'exclusion avec le mécanisme de configuration XML n'affecte pas les transferts d'appareil à appareil, mais affecte toujours la sauvegarde et la restauration dans 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 exécutées sur Android 12 et versions ultérieures et ciblant ces versions utilisent un format différent pour la configuration XML. Ce format rend explicite la différence entre la sauvegarde Google Drive et le transfert D2D en vous obligeant à spécifier des règles d'inclusion et d'exclusion distinctes pour les sauvegardes cloud et 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 sous 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 sur la 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 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 pour les applications qui ne nécessitent pas 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 simultanée d'égal à égal et connexion Internet

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 à l'appareil pair et au réseau principal fournissant Internet, ce qui améliore l'expérience utilisateur. Les applications ciblant Android 11 (niveau d'API 30) ou une version antérieure continuent de présenter 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 le WifiInfo que pour un seul réseau. C'est pourquoi le comportement de l'API a été modifié comme suit 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 pair à pair, 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 pair à pair, le WifiInfo de la connexion Internet principale est renvoyé.

Pour offrir une meilleure expérience utilisateur sur les appareils compatibles avec les réseaux Wi-Fi simultanés doubles, 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 à la place NetworkCallback.onCapabilitiesChanged() pour obtenir tous les objets WifiInfo correspondant au NetworkRequest utilisé pour enregistrer le 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 le moment où 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 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 réduire l'utilisation de la batterie, sur 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, puis l'arrête.

Étant donné que ce changement affecte la disponibilité du daemon mDNSResponder, 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.