Changements de comportement: applications ciblant Android 12

Comme dans les versions précédentes, Android 12 apporte des modifications de comportement susceptibles d'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 accepte 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 entraînait la création d'anti-modèles susceptibles de perturber les utilisateurs ou de provoquer 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'utiliseront 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 dans tous les états, telles que 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'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 à analyser, 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 un état 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 tester le nouveau modèle dès que possible.

  1. Activez la modification des notifications personnalisées:

    1. Remplacez targetSdkVersion de votre application par S pour activer le nouveau comportement.
    2. Recompilez.
    3. Installez votre application sur un appareil ou un émulateur sous Android 12.
  2. Testez toutes les notifications qui utilisent des vues personnalisées pour vous assurer qu'elles s'affichent comme vous le souhaitez dans le volet. Lors des tests, tenez compte de ces considérations et effectuez les ajustements nécessaires:

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

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

    • Pour vous assurer que l'état "Lever la tête" correspond à vos attentes, n'oubliez pas d'augmenter l'importance du canal de notification sur "ÉLEVÉE" (s'affiche à l'écran).

Dans les applications qui ciblent Android 12 ou version ultérieure, le système apporte plusieurs modifications à la validation d'Android App Links. Ces modifications améliorent la fiabilité de l'expérience d'association d'applications et offrent davantage de contrôle aux développeurs d'applications et aux utilisateurs finaux.

Si vous utilisez 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 Links. Assurez-vous en particulier que ces filtres d'intent incluent la catégorie BROWSABLE et 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 Picture-in-picture

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

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

Refonte de 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 d'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 notifications toast.

Sécurité et confidentialité

Position approximative

Sur les appareils équipés d'Android 12 ou version ultérieure, les utilisateurs peuvent demander la 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 sur lequel repose le navigateur Chrome de Google. Chromium a apporté des modifications au traitement 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 sur le même site. Les modifications suivantes visant à protéger la confidentialité améliorent la gestion par défaut des cookies tiers et contribuent à la protection contre le partage intersite 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.

Il est généralement conseillé aux développeurs d'identifier les dépendances de cookies intersites dans vos parcours utilisateur critiques et de s'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 des sites Web ou sur des navigations sur un même site qui passent du protocole HTTP au protocole HTTPS.

Pour obtenir des conseils complets pour les développeurs Web sur ces modifications, consultez Explication des cookies SameSite et Schemeful SameSite.

Tester les comportements de 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.

Surveillez les problèmes de connexion et de contenu intégré, ainsi que les flux de connexion, d'achat et autres 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 l'indicateur d'UI webview-enable-modern-cookie-same-site dans les outils de développement WebView.

    Cette approche vous permet d'effectuer des tests 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 89.0.4385.0 ou version ultérieure.

  • Compilez votre application pour cibler Android 12 (niveau d'API 31) en 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 son déploiement dans Chrome et WebView, consultez la page des mises à jour de Chromium SameSite. Si vous détectez un bug dans WebView ou Chromium, vous pouvez le signaler dans l'outil de suivi des problèmes Chromium public.

Le débit des capteurs de mouvement est limité

Pour protéger les informations potentiellement sensibles sur les utilisateurs, si votre application cible Android 12 ou une 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 la fait passer 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 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 spécifique d'accès aux données.

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 protéger les 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 une version ultérieure, lorsqu'un utilisateur exécute la commande adb backup, les données de l'application sont exclues de toute autre donnée système exportée depuis l'appareil.

Si vos workflows de test ou de développement s'appuient sur des données d'application utilisant adb backup, vous pouvez maintenant 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'

Modabilité 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 renforce la sécurité de votre application.

Tester la modification de mutabilité de l'intent 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]

Lancements d'intents non sécurisés

Pour améliorer la sécurité de la plate-forme, Android 12 et 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 lancement non sécurisé, un cas de non-respect du StrictMode se produit.

Performances

Restrictions de lancement des services de premier plan

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

Envisagez d'utiliser WorkManager pour planifier et démarrer 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éciaux des applis dans les paramètres système.

Pour obtenir cet accès spécial, 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 le changement 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 compatibilité des applications. 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 lance à terme 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, les applications qui ciblent Android 12 ou 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, une fois que l'utilisateur a appuyé sur une notification ou sur un bouton d'action dans la notification, votre application ne peut pas appeler startActivity() dans un service ou 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é. 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 joué le rôle de 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 du résultat inclut le texte "NotifInteractionLog". Cette section contient les informations nécessaires pour identifier le composant qui démarre à la suite d'une pression sur une notification.

Mettre à jour votre appli

Si votre application lance 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 lorsqu'ils appuient 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 une journalisation, par exemple, utilisez des extras lorsque vous publiez la notification. Pour une 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é NOTIFICATION_TRAMPOLINE_BLOCK.

Sauvegarder et restaurer

Des modifications ont été apportées au fonctionnement de la sauvegarde et de la restauration dans les applications qui s'exécutent sur Android 12 (niveau d'API 31) et la ciblent. 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 de l'utilisateur afin de pouvoir ultérieurement les restaurer sur cet appareil ou sur un nouvel appareil.
  • Transferts d'appareil à appareil (D2D):les données utilisateur sont envoyées directement au nouvel appareil à partir de l'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 des données utilisateur avec la sauvegarde automatique et Sauvegarder des paires clé/valeur avec Android Backup Service.

Modifications apportées aux fonctionnalités de transfert D2D

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

  • La spécification de règles d'inclusion et d'exclusion avec le mécanisme de configuration XML n'a aucune incidence sur les transferts D2D, mais elle 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 dans Google Drive, mais ne désactive pas les transferts D2D pour l'application.

Nouveau format "Inclure" et "Exclure"

Les applications exécutées sur Android 12 ou version ultérieure qui ciblent Android 12 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, car il vous oblige à 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. 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 apportées au format XML

Voici le format utilisé pour la configuration de la sauvegarde et de la restauration sous 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>

Vous trouverez ci-dessous les modifications apportées au format en gras.

<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 du 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 qui ciblent Android 12 d'interagir 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 à 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 récent.

Peer-to-peer + connexion Internet 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 à l'appareil pair et au réseau principal fournissant un accès à 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 rencontrer l'ancien comportement, où le réseau Wi-Fi principal est déconnecté avant la connexion à l'appareil associé.

Compatibilité

WifiManager.getConnectionInfo() peut renvoyer le WifiInfo 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 appelante 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 appelante n'a pas déclenché de connexion peer-to-peer, 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 doubles simultanés, nous vous recommandons d'utiliser toutes les applications (en particulier celles qui déclenchent des connexions peer-to-peer) plutôt que WifiManager.getConnectionInfo() et d'utiliser 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 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 lançait le daemon mDNSResponder, même si l'application n'avait appelé aucune méthode NsdManager. Le daemon a ensuite inscrit l'appareil aux groupes de multidiffusion "all-nodes" (tous les nœuds), ce qui a entraîné une activation plus fréquente du système et une consommation d'énergie supplémentaire. Pour minimiser l'utilisation de la batterie, à partir d'Android 12, le système ne démarre le daemon mDNSResponder que lorsque cela 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 est 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, mais pas l'API native mDNSResponder, ne sont pas concernées par cette modification.

Bibliothèques de fournisseurs

Bibliothèques partagées natives fournies par les fournisseurs

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 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 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. Toutefois, bien que vous puissiez actuellement utiliser certaines interfaces non SDK (en fonction du niveau d'API cible de votre application), l'utilisation d'une méthode ou d'un champ 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 des interfaces non SDK dans Android 12. Pour en savoir plus sur les interfaces non SDK de manière générale, consultez la section Restrictions concernant les interfaces non SDK.