Changements de comportement : toutes les applications

La plate-forme Android 12 apporte des modifications de comportement qui peuvent affecter votre application. Les changements de comportement suivants s'appliquent à toutes les applications lorsqu'elles s'exécutent sur Android 12, quel que soit le targetSdkVersion. Vous devez tester votre application, puis la modifier si nécessaire afin de prendre en charge ces modifications, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui n'affectent que les applications ciblant Android 12.

Expérience utilisateur

Effet de défilement hors limites d'étirement

Sur les appareils équipés d'Android 12 ou version ultérieure, le comportement visuel des événements de défilement hors limites change.

Sur Android 11 et versions antérieures, un événement de défilement hors limites élimine le halo des éléments visuels. Sur Android 12 et versions ultérieures, les éléments visuels s'étirent et rebondissent lors d'un événement de déplacement et rebondissent en cas de glissement d'un geste vif.

Pour en savoir plus, consultez le guide sur l'animation des gestes de défilement.

Écrans de démarrage de l'application

Si vous avez déjà implémenté un écran de démarrage personnalisé sous Android 11 ou version antérieure, vous devrez migrer votre application vers l'API SplashScreen pour vous assurer qu'elle s'affiche correctement à partir d'Android 12. Si vous ne migrez pas votre application, cela entraînera une dégradation ou une expérience de lancement inattendue.

Pour obtenir des instructions, consultez Migrer l'implémentation existante de votre écran de démarrage vers Android 12.

De plus, à partir d'Android 12, le système applique toujours le nouvel écran de démarrage par défaut du système Android aux démarrages à froid et aux démarrages à chaud pour toutes les applications. Par défaut, cet écran de démarrage système par défaut est créé à l'aide de l'élément d'icône de lanceur de votre application et du windowBackground de votre thème (s'il s'agit d'une couleur unie).

Pour en savoir plus, consultez le guide du développeur sur les écrans de démarrage.

Résolution des intents Web

À partir d'Android 12 (niveau d'API 31), un intent Web générique ne résout une activité dans votre application que si celle-ci est approuvée pour le domaine spécifique contenu dans cet intent Web. Si votre application n'est pas approuvée pour le domaine, l'intent Web se résout au niveau de l'application de navigateur par défaut de l'utilisateur.

Les applications peuvent obtenir cette approbation en effectuant l'une des opérations suivantes:

Si votre application appelle des intents Web, envisagez d'ajouter une invite ou une boîte de dialogue demandant à l'utilisateur de confirmer l'action.

Améliorations apportées au mode immersif pour la navigation par gestes

Android 12 regroupe le comportement existant pour permettre aux utilisateurs d'exécuter plus facilement des commandes de navigation par gestes en mode immersif. En outre, Android 12 fournit un comportement de rétrocompatibilité pour le mode immersif persistant.

Display#getRealSize et getRealMetrics: abandon et contraintes

Les appareils Android sont disponibles dans de nombreux facteurs de forme différents, tels que les grands écrans, les tablettes et les pliables. Pour afficher le contenu de manière appropriée pour chaque appareil, votre application doit déterminer la taille de l'écran ou de l'affichage. Au fil du temps, Android a fourni différentes API pour récupérer ces informations. Dans Android 11, nous avons introduit l'API WindowMetrics et avons abandonné les méthodes suivantes:

Dans Android 12, nous continuons à vous recommander d'utiliser WindowMetrics et nous abandonnons les méthodes suivantes:

Pour atténuer le comportement des applications qui utilisent les API Display pour récupérer les limites de l'application, Android 12 limite les valeurs renvoyées par les API pour les applications qui ne sont pas entièrement redimensionnables. Cela peut avoir un impact sur les applications qui utilisent ces informations avec MediaProjection.

Les applications doivent utiliser les API WindowMetrics pour interroger les limites de leur fenêtre et Configuration.densityDpi pour interroger la densité actuelle.

Pour une plus grande compatibilité avec les anciennes versions d'Android, vous pouvez utiliser la bibliothèque Jetpack WindowManager, qui inclut une classe WindowMetrics compatible avec Android 4.0 (niveau d'API 14) ou version ultérieure.

Exemples d'utilisation de WindowMetrics

Tout d'abord, assurez-vous que les activités de votre application sont entièrement redimensionnables.

Une activité doit s'appuyer sur WindowMetrics à partir d'un contexte d'activité pour toute tâche liée à l'UI, en particulier WindowManager.getCurrentWindowMetrics() ou WindowMetricsCalculator.computeCurrentWindowMetrics() de Jetpack.

Si votre application crée un MediaProjection, les limites doivent être correctement dimensionnées, car la projection capture la partition d'affichage dans laquelle l'application de projecteur est en cours d'exécution.

Si l'application est entièrement redimensionnable, le contexte d'activité renvoie les limites appropriées comme suit:

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Java

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Si l'application n'est pas entièrement redimensionnable, elle doit interroger une instance WindowContext et récupérer le WindowMetrics des limites de l'activité à l'aide de WindowManager.getMaximumWindowMetrics() ou de la méthode Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Java

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Toutes les applis en mode multifenêtre

Android 12 rend le mode multifenêtre standard.

Sur les grands écrans (SW >= 600 dp), la plate-forme accepte toutes les applications en mode multifenêtre, quelle que soit leur configuration. Si resizeableActivity="false", l'application passe en mode de compatibilité si nécessaire pour s'adapter aux dimensions d'affichage.

Sur les petits écrans (SW < 600 dp), le système vérifie les valeurs minWidth et minHeight d'une activité pour déterminer si elle peut s'exécuter en mode multifenêtre. Si la valeur est resizeableActivity="false", l'application ne peut pas s'exécuter en mode multifenêtre, quelles que soient la largeur et la hauteur minimales.

Pour en savoir plus, consultez la page Compatibilité avec le mode multifenêtre.

Aperçu de l'appareil photo sur grand écran

Les applications d'appareil photo supposent généralement une relation fixe entre l'orientation de l'appareil et le format de l'aperçu de l'appareil photo. Toutefois, les facteurs de forme sur grand écran (tels que les appareils pliables) et les modes d'affichage (multifenêtre et multi-écran, par exemple) remettent en question cette hypothèse.

Sous Android 12, les applications d'appareil photo qui demandent une orientation spécifique de l'écran et qui ne sont pas redimensionnables (resizeableActivity="false") passent automatiquement en mode Portrait en incrustation, ce qui garantit l'orientation et le format corrects de l'aperçu de l'appareil photo. Sur les appareils pliables et autres appareils dotés d'une couche d'abstraction matérielle (HAL), une rotation supplémentaire est appliquée à la sortie de la caméra pour compenser l'orientation du capteur de l'appareil photo, et la sortie de la caméra est recadrée pour correspondre au format de l'aperçu de l'appareil photo de l'application. Le recadrage et la rotation supplémentaire garantissent une présentation correcte de l'aperçu de l'appareil photo, indépendamment de l'orientation de l'appareil et de son état plié ou déplié.

Délai de l'expérience utilisateur pour les notifications de services de premier plan

Afin de simplifier l'expérience pour les services de premier plan de courte durée, les appareils équipés d'Android 12 ou version ultérieure peuvent retarder l'affichage des notifications de services de premier plan de 10 secondes, à quelques exceptions. Cette modification permet aux tâches de courte durée de s'achever avant que leurs notifications n'apparaissent.

Performances

Bucket de mise en veille des applications limité

Android 11 (niveau d'API 30) a introduit le bucket restreint en tant que bucket de mise en veille des applications. À partir d'Android 12, ce bucket est actif par défaut. Le bucket "restricted" a la priorité la plus basse (et les restrictions les plus élevées) de tous les buckets. Les buckets sont classés par ordre de priorité (de la plus élevée à la plus faible) :

  1. Active: l'application est en cours d'utilisation ou a été utilisée très récemment.
  2. Ensemble de travail: l'application est utilisée régulièrement.
  3. Fréquent: l'application est souvent utilisée, mais pas tous les jours.
  4. Rare: l'application n'est pas souvent utilisée.
  5. Restreint: l'application utilise une grande quantité de ressources système ou peut présenter un comportement indésirable.

Le système prend en compte le comportement de votre application, en plus des modèles d'utilisation, pour décider de la placer dans le bucket "restricted".

Votre application est moins susceptible d'être placée dans le bucket "restricted" si elle utilise les ressources système de manière plus responsable. En outre, le système place votre application dans un bucket moins restrictif si l'utilisateur interagit directement avec elle.

Vérifier si votre appli se trouve dans le bucket "restricted"

Pour vérifier si le système a placé votre application dans le bucket "restricted", appelez getAppStandbyBucket(). Si la valeur renvoyée par cette méthode est STANDBY_BUCKET_RESTRICTED, votre application se trouve dans le bucket "restricted".

Tester le comportement du bucket "restricted"

Pour tester le comportement de votre application lorsque le système la place dans le bucket "restricted", vous pouvez la déplacer manuellement vers ce bucket. Pour ce faire, exécutez la commande suivante dans une fenêtre de terminal:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Sécurité et confidentialité

Position approximative

La boîte de dialogue comporte deux ensembles d&#39;options, l&#39;un au-dessus de l&#39;autre
Figure 1. Boîte de dialogue des autorisations système, qui permet à l'utilisateur d'accorder des informations de localisation approximatives.

Sur les appareils équipés d'Android 12 ou version ultérieure, les utilisateurs peuvent demander à votre application d'accéder uniquement aux informations de localisation approximatives.

Si votre application demande l'autorisation d'exécution ACCESS_FINE_LOCATION, vous devez également demander l'autorisation ACCESS_COARSE_LOCATION pour gérer le cas où l'utilisateur accorde un accès à la position approximative à votre application. Vous devez inclure les deux autorisations dans une seule requête d'exécution.

La boîte de dialogue des autorisations système inclut les options suivantes pour l'utilisateur, comme illustré dans la figure 1:

  • Exacte: permet d'accéder à des informations de position précises.
  • Approximative: seules les informations de position approximatives sont accessibles.

Activation/Désactivation du micro et de l'appareil photo

Les appareils compatibles équipés d'Android 12 ou version ultérieure permettent aux utilisateurs d'activer et de désactiver l'accès à l'appareil photo et au micro pour toutes les applications de l'appareil en appuyant sur une seule option d'activation/désactivation. Les utilisateurs peuvent accéder aux options à activer/désactiver depuis les Réglages rapides, comme le montre la figure 1, ou depuis l'écran "Confidentialité" dans les paramètres système.

Découvrez ces boutons d'activation/de désactivation et comment vérifier que votre application respecte les bonnes pratiques concernant les autorisations CAMERA et RECORD_AUDIO.

Indicateurs d'accès au micro et à l'appareil photo

Sur les appareils équipés d'Android 12 ou version ultérieure, lorsqu'une application accède au micro ou à l'appareil photo, une icône s'affiche dans la barre d'état.

Pour en savoir plus sur ces indicateurs et sur la manière de vérifier que votre application respecte les bonnes pratiques concernant les autorisations CAMERA et RECORD_AUDIO,

Les blocs &quot;Réglages rapides&quot; sont intitulés &quot;Accès à l&#39;appareil photo&quot; et &quot;Accès au micro&quot;.
Figure 2. Boutons d'activation/de désactivation de l'accès au micro et à l'appareil photo dans les réglages rapides.
Rectangle arrondi en haut à droite, contenant une icône d&#39;appareil photo et une icône de micro
Figure 3. Indicateurs d'accès au micro et à l'appareil photo montrant l'accès récent aux données.

Visibilité des packages d'autorisations

Sur les appareils équipés d'Android 12 ou version ultérieure, les applications qui ciblent Android 11 (niveau d'API 30) ou version ultérieure et qui appellent l'une des méthodes suivantes reçoivent un ensemble de résultats filtré, en fonction de la visibilité du package dans d'autres applications:

Implémentation de BouncyCastle supprimée

Android 12 supprime de nombreuses implémentations BouncyCastle d'algorithmes cryptographiques précédemment obsolètes, y compris tous les algorithmes AES. Le système utilise à la place les implémentations Conscrypt de ces algorithmes.

Cette modification affecte votre application si l'une des conditions suivantes est remplie:

  • Votre application utilise une taille de clé de 512 bits. Conscrypt n'est pas compatible avec cette taille de clé. Si nécessaire, mettez à jour la logique de cryptographie de votre application pour utiliser différentes tailles de clé.
  • Votre application utilise des tailles de clé non valides avec KeyGenerator. L'implémentation de KeyGenerator par Conscrypt effectue une validation supplémentaire sur les paramètres de clé par rapport à BouncyCastle. Par exemple, Conscrypt ne permet pas à votre application de générer une clé AES 64 bits, car AES n'accepte que les clés de 128, 192 et 256 bits.

    BouncyCastle permet de générer des clés de tailles non valides, mais échoue ultérieurement si ces clés sont utilisées avec un Cipher. Conscrypt échoue plus tôt.

  • Vous initialisez vos algorithmes de chiffrement GCM (Galois/Counter Mode) en utilisant une taille autre que 12 octets. L'implémentation de GcmParameterSpec par Conscrypt nécessite une initialisation de 12 octets, ce qui est recommandé par le NIST.

Notifications d'accès au presse-papiers

Sur Android 12 ou version ultérieure, lorsqu'une application appelle getPrimaryClip() pour accéder aux données d'extraits d'une autre application pour la première fois, un toast informe l'utilisateur de l'accès au presse-papiers.

Le texte inclus dans le toast est au format suivant : APP pasted from your clipboard.

Informations sur le texte de la description de l'extrait

Sur Android 12 ou version ultérieure, getPrimaryClipDescription() peut détecter les informations suivantes:

Les applis ne peuvent pas fermer les boîtes de dialogue système

Pour améliorer le contrôle des utilisateurs lorsqu'ils interagissent avec les applications et le système, l'action d'intent ACTION_CLOSE_SYSTEM_DIALOGS est obsolète depuis Android 12. Sauf dans quelques cas particuliers, lorsque votre application tente d'appeler un intent contenant cette action, le système effectue l'une des opérations suivantes en fonction de la version du SDK cible de votre application:

  • Si votre application cible Android 12 ou une version ultérieure, une SecurityException se produit.
  • Si votre application cible Android 11 (niveau d'API 30) ou une version antérieure, l'intent ne s'exécute pas et le message suivant s'affiche dans Logcat:

    E ActivityTaskManager Permission Denial: \
    android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
    com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
    dropping broadcast.
    

Exceptions

Dans les cas suivants, une application peut toujours fermer les boîtes de dialogue système sous Android 12 ou version ultérieure:

  • Votre application exécute un test d'instrumentation.
  • Votre application cible Android 11 ou version antérieure et affiche une fenêtre en haut du panneau des notifications.

  • Votre application cible Android 11 ou version antérieure. En outre, l'utilisateur a interagi avec une notification, peut-être à l'aide des boutons d'action de la notification, et votre application traite un service ou un broadcast receiver en réponse à cette action de l'utilisateur.

  • Votre application cible Android 11 ou version antérieure et dispose d'un service d'accessibilité actif. Si votre application cible Android 12 et souhaite fermer la barre de notification, utilisez plutôt l'action d'accessibilité GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Les événements tactiles non approuvés sont bloqués

Pour préserver la sécurité du système et une bonne expérience utilisateur, Android 12 empêche les applications de consommer des événements tactiles lorsqu'une superposition masque l'application de manière non sécurisée. En d'autres termes, les blocs système qui passent par certaines fenêtres, à quelques exceptions,

Applications concernées

Cette modification affecte les applications qui choisissent d'autoriser la transmission des éléments tactiles via leurs fenêtres, par exemple à l'aide de l'indicateur FLAG_NOT_TOUCHABLE. Voici quelques exemples (liste non exhaustive) :

  • Les superpositions qui nécessitent l'autorisation SYSTEM_ALERT_WINDOW, telles que les fenêtres qui utilisent TYPE_APPLICATION_OVERLAY, et utilisent l'option FLAG_NOT_TOUCHABLE.
  • Fenêtres d'activité qui utilisent l'indicateur FLAG_NOT_TOUCHABLE

Exceptions

Dans les cas suivants, les gestes "passthrough" sont autorisés:

  • Interactions dans votre application : votre application affiche la superposition, qui n'apparaît que lorsque l'utilisateur interagit avec elle.
  • Fenêtres de confiance. Ces périodes incluent (sans s'y limiter) les suivantes:

  • Fenêtres invisibles. La vue racine de la fenêtre correspond à GONE ou INVISIBLE.

  • Des fenêtres totalement transparentes La propriété alpha est de 0.0 pour la fenêtre.

  • Fenêtres d'alerte système suffisamment transparentes. Le système considère qu'un ensemble de fenêtres d'alerte système est suffisamment translucide lorsque l'opacité combinée est inférieure ou égale à l'opacité d'obscurcissement maximale du système pour les gestes tactiles. Sous Android 12, cette opacité maximale est de 0,8 par défaut.

Détecter lorsqu'un appareil tactile non fiable est bloqué

Si une action tactile est bloquée par le système, Logcat consigne le message suivant:

Untrusted touch due to occlusion by PACKAGE_NAME

Tester le changement

Les éléments tactiles non approuvés sont bloqués par défaut sur les appareils équipés d'Android 12 ou version ultérieure. Pour autoriser les éléments tactiles non fiables, exécutez la commande ADB suivante dans une fenêtre de terminal:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Pour rétablir le comportement par défaut (les éléments tactiles non approuvés sont bloqués), exécutez la commande suivante:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Cycle de vie d'une activité

Les activités du lanceur d'applications racine ne sont plus terminées en cas d'appui sur le bouton Retour

Android 12 modifie la gestion par défaut de l'appui arrière du système pour les activités du lanceur d'applications qui se trouvent à la racine de ses tâches. Dans les versions précédentes, le système mettait fin à ces activités en appuyant sur le bouton Retour. Dans Android 12, le système déplace désormais l'activité et sa tâche en arrière-plan au lieu de les terminer. Le nouveau comportement correspond au comportement actuel lorsque vous quittez une application à l'aide du bouton d'accueil ou d'un geste.

Pour la plupart des applications, ce changement signifie que les utilisateurs qui utilisent la fonctionnalité Retour pour quitter votre application peuvent la réactiver plus rapidement à partir d'un état tiède, au lieu d'avoir à la redémarrer complètement à partir d'un état à froid.

Nous vous recommandons de tester vos applications avec cette modification. Si votre application ignore actuellement onBackPressed() pour gérer le retour arrière et terminer le Activity, mettez à jour votre implémentation pour appeler super.onBackPressed() au lieu de terminer. Appeler super.onBackPressed() déplace l'activité et sa tâche en arrière-plan le cas échéant, et offre une expérience de navigation plus cohérente entre les applications.

Notez également qu'en général, nous recommandons d'utiliser les API d'activité AndroidX pour fournir un retour arrière personnalisé, plutôt que de remplacer onBackPressed(). Les API Activity d'AndroidX s'appliquent automatiquement au comportement approprié du système si aucun composant n'intercepte l'appui sur le bouton Retour du système.

Graphiques et images

Amélioration du changement de fréquence d'actualisation

Dans Android 12, les modifications de la fréquence d'actualisation à l'aide de setFrameRate() peuvent se produire, que l'écran prenne en charge ou non une transition fluide vers la nouvelle fréquence d'actualisation. Une transition fluide est une transition qui ne présente aucune interruption visuelle, comme un écran noir pendant une seconde ou deux. Auparavant, si l'écran ne permettait pas une transition fluide, il continuait généralement à utiliser la même fréquence d'actualisation après l'appel de setFrameRate(). Vous pouvez déterminer à l'avance si la transition vers la nouvelle actualisation sera fluide en appelant getAlternativeRefreshRates(). En règle générale, le rappel onDisplayChanged() est appelé une fois le changement de fréquence d'actualisation terminé, mais pour certains écrans connectés en externe, il est appelé lors d'une transition non fluide.

Voici un exemple de mise en œuvre:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Java

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Connectivité

Mises à jour Passpoint

Les API suivantes sont ajoutées dans Android 12:

  • isPasspointTermsAndConditionsSupported() : les Conditions d'utilisation sont une fonctionnalité Passpoint qui permet aux déploiements réseau de remplacer les portails captifs non sécurisés, qui utilisent des réseaux ouverts, par un réseau Passpoint sécurisé. Une notification s'affiche lorsque l'utilisateur doit accepter les conditions d'utilisation. Les applications qui suggèrent des réseaux Passpoint protégés par des conditions d'utilisation doivent d'abord appeler cette API pour s'assurer que l'appareil est compatible avec cette fonctionnalité. Si l'appareil n'est pas compatible avec cette fonctionnalité, il ne pourra pas se connecter à ce réseau, et un réseau alternatif ou ancien doit être suggéré.
  • isDecoratedIdentitySupported() : lors de l'authentification auprès de réseaux avec une décoration de préfixe, le préfixe d'identité décoré permet aux opérateurs réseau de mettre à jour l'identifiant d'accès au réseau (NAI) pour effectuer un routage explicite via plusieurs proxys au sein d'un réseau AAA (pour en savoir plus, consultez le document RFC 7542).

    Android 12 implémente cette fonctionnalité afin de se conformer à la spécification WBA pour les extensions PPS-MO. Les applications qui suggèrent des réseaux Passpoint nécessitant une identité décorée doivent d'abord appeler cette API pour s'assurer que l'appareil est compatible avec cette fonctionnalité. Si l'appareil n'est pas compatible avec cette fonctionnalité, l'identité ne sera pas décorée et l'authentification auprès du réseau peut échouer.

Pour créer une suggestion Passpoint, les applications doivent utiliser les classes PasspointConfiguration, Credential et HomeSp. Ces classes décrivent le profil Passpoint, qui est défini dans la spécification Passpoint de Wi-Fi Alliance.

Pour en savoir plus, consultez la section API Wi-Fi Suggestion pour la connectivité Internet.

Mise à jour des restrictions des interfaces 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.