Modifications de comportement : applications ciblant Android 12

Comme les versions précédentes, Android 12 inclut 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 prendre en charge ces comportements correctement, le cas échéant.

N'oubliez pas de consulter également la liste des modifications de comportement qui affectent toutes les applications exécutées sous 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 pouvant prêter à confusion 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, comme l'icône et les affordances d'expansion de la notification (dans l'état réduit) et l'icône, le nom de l'application et l'affordance de réduction de la notification (dans l'état développé). 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 expansion de notification 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 à l'é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 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 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 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 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 réduit.

    • 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 "Attention" s'affiche comme prévu, n'oubliez pas de définir l'importance du canal de notification sur "HIGH" (populations à l'écran).

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 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 tout particulièrement 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éliorations du comportement du mode 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 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 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 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 la précision de la position approximative pour votre application.

Cookies modernes SameSite dans WebView

Le composant WebView d'Android est basé sur Chromium, le projet Open Source qui alimente 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 suivantes concernant la protection de la confidentialité améliorent le traitement par défaut des cookies tiers et contribuent à vous 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 destinés aux développeurs Web sur ces modifications, 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 prendre en charge les nouveaux comportements 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:

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

Exportation des 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, 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 qu'elle crée. Cette exigence supplémentaire renforce la sécurité de votre application.

Tester le changement de mutabilité des intents en attente

Pour déterminer si votre application manque 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 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 build débogable à des fins de test. Pour ce faire, effectuez l'une des tâches suivantes:

  • Sur l'écran des paramètres Developer options (Options pour les développeurs), sélectionnez App Compatibility Changes (Modifications de la 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 sur 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, 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 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 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 à 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é, par exemple pour effectuer une journalisation, utilisez des extras lors de la publication de 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é de l'application 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 et ciblent Android 12 (niveau d'API 31). La sauvegarde et la restauration Android se présentent sous deux formes:

  • Sauvegardes dans le cloud : les données utilisateur sont stockées dans Google Drive afin de pouvoir être restaurées ultérieurement sur cet appareil ou sur un autre.
  • Transferts d'appareil à appareil (D2D):les données utilisateur sont envoyées directement au nouvel appareil de l'utilisateur à partir de 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 é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

Le format suivant est 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 de 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 é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 plus moderne d'autorisations Bluetooth.

Connexion peer-to-peer + connexion Internet simultanée

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 continuent de subir 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. Pour cette raison, 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 pair à pair, 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 point à point, la WifiInfo de la connexion Internet principale est renvoyée.

Pour améliorer l'expérience utilisateur sur les appareils compatibles avec les réseaux Wi-Fi à double simultané, 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 au 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 mDNSResponseer

Android 12 change lorsque les applications peuvent interagir avec le daemon mDNSResponseer à l'aide de l'API native mDNSRépondre. Auparavant, lorsqu'une application enregistré un service sur le réseau et appelait la méthode getSystemService(), le service NSD du système démarrait le daemon mDNSResponseer, même si l'application n'avait encore appelé aucune méthode 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 mDNSResponder ne sont pas concernées par ce changement.

Bibliothèques de fournisseurs

Bibliothèques partagées natives fournies par les fournisseurs

Les bibliothèques partagées natives ne faisant pas partie du NDK fournies par les fournisseurs de silicium 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 version antérieure, la balise <uses-native-library> n'est pas requise. Dans ce cas, toute 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. 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 de manière générale, consultez la section Restrictions concernant les interfaces non SDK.