Changements de comportement: applications ciblant Android 12

Comme les versions précédentes, Android 12 inclut des modifications de comportement qui peut affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 12 ou version ultérieure. Si votre application est ciblant Android 12, vous devez modifier votre appli pour qu'elle accepte ces comportements correctement, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications fonctionnant 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 toute la zone de notification et fournissent leurs propres mises en page et styles. Cela a engendré des anti-modèles qui pourrait 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 l'intégralité de la zone de notification ; le système applique une règle modèle. Ce modèle garantit que les notifications personnalisées ont le même que les autres notifications quel que soit leur état, comme l'icône de notification et les affordances d'expansion (à l'état réduit) et l'icône de notification, nom de l'application et affordance de réduction (à l'état développé). Ce comportement est presque identique au comportement Notification.DecoratedCustomViewStyle

Ainsi, Android 12 rend toutes les notifications visuellement cohérentes et faciles à 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 groupe réduit et en grand format:

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

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

  1. Activer 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 exécutant Android 12.

  2. Testez toutes les notifications qui utilisent des vues personnalisées et assurez-vous qu'elles apparaissent comme vous. s’attendent à l’ombre. Tenez compte de ces considérations lors des tests et effectuez les ajustements nécessaires:

    • Les dimensions des vues personnalisées ont changé. En général, la hauteur pour les notifications personnalisées est moins élevé qu'auparavant. Dans la vue réduite , 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 général, cela signifie que si vous utilisez setCustomContentView, vous devez également utiliser setBigCustomContentView pour garantir la cohérence des états réduit et développé.

    • Pour vous assurer que la fonctionnalité l'état attendu, n'oubliez pas pour accorder l'importance du canal de notification à "HIGH" (S'ouvre sur l'écran).

Dans les applications qui ciblent Android 12 ou version ultérieure, le système plusieurs modifications ont été apportées à la façon dont Android App Links validé. Ces améliorent la fiabilité de l'expérience d'association d'applications et offrent aux développeurs d'applications et aux utilisateurs finaux.

Si vous utilisez la validation Android App Links pour ouvrir des liens Web dans votre appli, vérifiez que vous utilisez le format approprié lorsque vous ajoutez un intent des filtres pour Validation Android App Links. Vérifiez en particulier que ces intents Les filtres incluent la catégorie BROWSABLE et sont compatibles avec le schéma https.

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

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

Android 12 améliore le comportement du mode Picture-in-picture (PIP), Améliorations esthétiques recommandées pour les animations de transition, aussi bien pour les gestes la navigation et la navigation basée sur les éléments.

Reportez-vous à la fonctionnalité Picture-in-picture d'assistance pour obtenir d'autres des informations.

Refonte de Toast

Sous Android 12, la vue toast repensé. Les toasts sont désormais limités à deux lignes de texte et affichent 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 notifications toast.

Sécurité et confidentialité

Position approximative

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

Cookies modernes SameSite dans WebView

Le composant WebView d'Android est basé sur Chromium. le projet Open Source sur lequel repose le navigateur Chrome de Google. Lancement de Chromium la gestion des cookies tiers pour renforcer la sécurité la confidentialité et d'offrir aux utilisateurs plus de transparence et de contrôle. À partir d'Android 12, ces modifications sont aussi incluses dans WebView lorsque les applis 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 ou seulement avec des requêtes SameSite. Les règles suivantes, qui protègent la confidentialité, améliorent la gestion par défaut des cookies tiers et contribuent contre le partage involontaire entre les 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 elles nécessitent un contexte sécurisé et doivent être envoyées via HTTPS.
  • Les liens entre les versions HTTP et HTTPS d'un site sont désormais traités comme des liens intersites les cookies ne sont pas envoyés, sauf s'ils sont correctement signalés comme SameSite=None; Secure

En règle générale, les développeurs doivent identifier le cookie intersites. dépendances dans vos flux utilisateur critiques et assurez-vous que SameSite est explicitement défini avec les valeurs appropriées, le cas échéant. Vous devez spécifier explicitement les cookies qui sont autorisés à fonctionner sur plusieurs sites Web ou lors de navigations sur le même site qui passent du HTTP au HTTPS.

Pour obtenir des conseils complets destinés aux développeurs Web concernant ces modifications, consultez SameSite Cookies. Explained (Explication) 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 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 le nouveau Comportements de SameSite.

Surveillez les problèmes de connexion, de contenu intégré et de connexion, d'achat et autres processus d'authentification où l'utilisateur commence et les transitions vers une page sécurisée.

Pour tester une application avec WebView, vous devez activer les nouveaux comportements SameSite pour la classe 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 de WebView sur Android, consultez la section Premiers pas avec 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 les mises à jour SameSite de Chromium . Si vous détectez un bug dans WebView ou Chromium, vous pouvez le signaler dans le site public bracelet d'activité.

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 version ultérieure, le système limite l'actualisation du débit de données de certains capteurs de mouvement et de position.

En savoir plus sur les capteurs limitation du débit.

Hibernation des applications

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

Pour en savoir plus, consultez le guide sur les applications l'hibernation.

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 pour créer une attribution de vos tags en fonction de vos les cas d'utilisation de l'application. Ces balises vous permettent de déterminer plus facilement quelle partie 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 des balises d'attribution dans le fichier manifeste de votre application.

Restriction de sauvegarde ADB

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

Si vos workflows de test ou de développement s'appuient sur des données d'application avec adb backup, vous pouvez désormais choisir d'exporter les données de votre application android:debuggable à 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 activités, services ou diffusion récepteurs qui utilisent des intents , vous devez explicitement déclarez le Attribut android:exported pour ces composants d'application.

Si le composant d'application inclut Catégorie LAUNCHER, définie android:exported à 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 intent filtre 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 sans déclarer android:exported, l'avertissement suivant messages 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 apparaît:

    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 essayez 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 le mutabilité de chaque objet PendingIntent que votre l'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 manque de déclarations de mutabilité, recherchez le 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 ou version ultérieure offre une de débogage qui détecte les lancements non sécurisés intents. Quand ? le système détecte un lancement aussi dangereux, 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 version ultérieure ne peuvent pas démarrer le premier plan services pendant l'exécution en contexte, à l'exception de quelques cas d'utilisation. Si une application tente de démarrer un service de premier plan alors qu'elle s'exécute dans le arrière-plan, une exception se produit (sauf dans les quelques cas particuliers).

Envisagez d'utiliser WorkManager pour planifier et démarrer les opérations travail lorsque votre application s'exécute en arrière-plan. Pour effectuer des actions urgentes qui à la demande de l'utilisateur, démarrez les services de premier plan avec un l'alarme.

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éfinissez exactement alarmes doivent avoir accès au menu "Alarmes rappels" qui apparaît sur l'écran Accès spéciaux des applis dans paramètres système.

Pour obtenir cet accès spécial, demandez le 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 des cas d'utilisation acceptables pour définir l'alarme.

Désactiver le changement de comportement

Lorsque vous préparez votre application pour cibler Android 12, vous pouvez temporairement désactiver le changement de comportement dans votre version débogable ; variante à des fins de test. Pour ce faire, effectuez l'une des tâches suivantes:

  • Sur l'écran de configuration Options pour les développeurs, sélectionnez Compatibilité des applications. Modifications. Sur l'écran qui s'affiche, appuyez sur le nom de votre application, puis désactivez-la. 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 notifications, certaines applications réagissent appuis sur une notification en lançant une application qui lance à terme activité que l'utilisateur voit enfin et avec laquelle il interagit. Ce composant d'application est C'est ce qu'on appelle un trampoline de notification.

Pour améliorer les performances et l'expérience utilisateur, les applications ciblant Android 12 ou ne peuvent pas démarrer d'activités depuis des services ou des broadcast receivers utilisés comme des trampolines de notification. En d'autres termes, après que l'utilisateur appuie sur une notification, ou un bouton d'action dans la 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 et le message suivant apparaît dans Logcat:

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

Identifier les composants d'application servant de trampolines de notification

Lorsque vous testez votre application, après avoir appuyé sur une notification, vous pouvez identifier ou broadcast receiver a servi 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 de la sortie inclut le texte "NotifInteractionLog". Cette section contient les informations nécessaires pour identifier le composant qui démarre après avoir appuyé sur une notification.

Mettre à jour votre appli

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

  1. Créez un objet PendingIntent qui est associé à l'activité que l'utilisateur voit après avoir appuyé sur .
  2. Utilisez l'objet PendingIntent que vous avez créé à l'étape précédente dans le cadre de de construire votre notification.

Pour identifier l'origine de l'activité, par exemple pour effectuer la journalisation, Utilisez des éléments supplémentaires lorsque vous publiez la notification. Pour une journalisation centralisée, utilisez ActivityLifecycleCallbacks ou observateurs du 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 fonctionnalité. à l'aide de l'indicateur de compatibilité d'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). La sauvegarde et la restauration Android se présentent sous deux formes:

  • Sauvegardes dans le cloud:les données de l'utilisateur sont stockées sur son Google Drive afin d'être peut être restauré plus tard sur cet appareil ou sur un nouvel appareil.
  • Transferts d'appareil à appareil (D2D):les données utilisateur sont directement envoyées au nouvel appareil de l'utilisateur à partir de son ancien appareil, par exemple en utilisant un câble.

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

Modifications apportées à la fonctionnalité de transfert D2D

Pour les applications fonctionnant sous Android 12 ou version ultérieure et ciblant Android 12:

  • Spécifier des règles d'inclusion et d'exclusion à l'aide du code XML n'affecte pas les transferts D2D. affecte la sauvegarde et la restauration dans le cloud (telles que les sauvegardes Google Drive). À spécifiez des règles pour les transferts D2D, vous devez utiliser la nouvelle configuration couverte dans la section suivante.

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

Nouveau format "Inclure" et "Exclure"

Les applications fonctionnant sous Android 12 ou version ultérieure et ciblant Android 12 ou version ultérieure utilisent un format différent pour la configuration XML. Ce format fait la différence entre la sauvegarde Google Drive et le transfert D2D explicite en vous demandant spécifier des règles d'inclusion et d'exclusion séparément pour les sauvegardes dans le cloud et pour D2D ; transfert.

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 plus élevée. L'ancienne configuration est toujours requise pour les appareils équipés d'Android 11 ou inférieure.

Modifications du format XML

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

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 dans le guide de 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 la méthode 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 le nouveau 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 BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, et BLUETOOTH_CONNECT autorisations. Ces autorisations permettent aux applications qui ciblent Android 12 pour interagir avec le Bluetooth appareils mobiles, en particulier pour les applications ont 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 de connexions Bluetooth les autorisations déclarer un ensemble de technologies Bluetooth plus moderne autorisations.

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 un même réseau Wi-Fi des connexions à la fois à l'appareil pair et au réseau principal fournissant Internet, rendant l'expérience utilisateur plus fluide. Ciblage par applications Android 11 (niveau d'API 30) ou version antérieure continue de subir l'ancien comportement : Le réseau Wi-Fi principal est déconnecté avant la connexion au pair. appareil.

Compatibilité

WifiManager.getConnectionInfo() peut renvoyer le WifiInfo pour un seul réseau. C'est pourquoi le comportement de l'API a été modifié dans des opérations suivantes sous Android 12 ou version ultérieure:

  • 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 alerte connexion pair à pair, le WifiInfo correspondant à l'appareil pair renvoyé.
  • Si plusieurs réseaux Wi-Fi sont disponibles et que l'application d'appel n'a pas répondu déclencher une connexion peer-to-peer, la connexion Internet principale WifiInfo est renvoyé.

Améliorer l'expérience utilisateur sur les appareils compatibles avec la double simultané Réseaux Wi-Fi, nous recommandons toutes les applis, surtout celles qui déclenchent les connexions peer-to-peer : abandonnez les appels WifiManager.getConnectionInfo() et utilisez à la place NetworkCallback.onCapabilitiesChanged() pour obtenir tous les objets WifiInfo correspondant au NetworkRequest utilisé pour enregistrer NetworkCallback. getConnectionInfo() est obsolète depuis le 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 mDNSResponseer. Auparavant, lorsqu'une application enregistré un service sur le réseau, et appelé getSystemService() , le service NSD du système a lancé le daemon mDNSResponseer, même si le l'application n'a appelé aucune méthode NsdManager pour le moment. Le daemon a ensuite abonné vers les groupes de multidiffusion tous les nœuds, ce qui entraîne une activation fréquemment et de consommer plus d'énergie. Pour réduire l'utilisation de la batterie, sous Android 12 Au-delà, le système ne démarre le daemon mDNSResponseer qu'en cas de besoin. pour les événements NSD et l'arrête ensuite.

Étant donné que ce changement affecte le moment où le daemon mDNSResponseer est disponible, les applications partent du principe que le daemon mDNSRépondreer est démarré après l'appel de la méthode La méthode getSystemService() peut recevoir des messages du système indiquant que le daemon mDNSRépondreer n'est pas disponible. Applications qui utilisent NsdManager et qui ne l'utilisent pas utiliser l'API native mDNSRépondreer ne sont pas concernés par ce changement.

Bibliothèques de fournisseurs

Bibliothèques partagées natives fournies par les fournisseurs

Bibliothèques partagées natives non NDK fournis 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. La les bibliothèques ne sont accessibles que lorsqu'elles sont explicitement demandées à l'aide de la méthode <uses-native-library> .

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

Mise à jour des restrictions non SDK

Android 12 inclut des listes à jour de listes d'autorisations non SDK limitées grâce à une collaboration avec des développeurs Android 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 pourrait ne pas vous affecter immédiatement. Toutefois, même si vous pouvez actuellement utiliser certaines Des 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é de casser votre l'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 la section Mises à jour de Restrictions d'interface non SDK dans Android 12 Pour en savoir plus sur les interfaces non SDK en général, consultez la section Restrictions concernant les interfaces non SDK interfaces Google Cloud.