La plate-forme Android 12 inclut des modifications de comportement qui peuvent
affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles
s'exécutent sur Android 12, quelle que soit la version 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 ne concernent que les applications. ciblant Android 12.
Expérience utilisateur
Effet étirer le défilement hors limites
Sur les appareils équipés d'Android 12 ou version ultérieure, le comportement visuel du défilement hors limites événements.
Sur Android 11 et versions antérieures, un événement de défilement hors limites entraîne la présence d'éléments visuels un halo ; Sur Android 12 ou version ultérieure, les éléments visuels s'étirent et rebondissent sur lors d'un événement de déplacement.
Pour en savoir plus, consultez le guide sur l'animation du défilement gestes.
Écrans de démarrage de l'application
Si vous avez déjà implémenté un écran de démarrage personnalisé sous Android 11 ou
à une version antérieure, vous devez migrer votre application vers l'API SplashScreen
pour vous assurer
elle s'affiche correctement
à partir d'Android 12. Si vous ne migrez pas votre application,
lors d'un lancement d'application dégradé ou inattendu.
Pour obtenir des instructions, consultez Migrer votre écran de démarrage existant vers Android 12.
De plus, à partir d'Android 12, le système applique toujours la nouvelle version d'Android
écran de démarrage système par défaut activé
froid et
démarrages tièdes pour toutes les applications
Par défaut, cet écran de démarrage système par défaut est construit à l'aide du
de l'icône de lanceur
windowBackground
de vos
(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 d'intent Web
À partir d'Android 12 (niveau d'API 31), un intent Web générique renvoie vers un l'activité dans votre application uniquement si celle-ci est approuvée pour le domaine concerné contenus dans cet intent Web. Si votre application n'est pas approuvée pour le domaine, le l'intent Web renvoie à l'application du navigateur par défaut de l'utilisateur.
Les applications peuvent obtenir cette approbation en effectuant l'une des opérations suivantes:
Validez le domaine à l'aide de l'application Android Liens.
Dans les applications qui ciblent Android 12 ou version ultérieure, le système modifie la façon dont automatiquement valide Android App Links pour votre application. Dans l'intent de votre application des filtres, vérifiez que vous incluez la catégorie
BROWSABLE
et que vous acceptez l'https
d'un schéma.Sur Android 12 ou version ultérieure, pouvez manuellement valider Android App Links de votre application, pour tester l'impact de cette nouvelle logique sur votre l'application.
Demandez à l'utilisateur d'associer votre application au domaine dans les paramètres système.
Si votre application appelle des intents Web, envisagez d'ajouter une invite ou une boîte de dialogue qui demande à l'utilisateur de confirmer l'action.
Améliorations du mode immersif pour la navigation par gestes
Android 12 consolide le comportement existant pour permettre aux utilisateurs de commandes de navigation par gestes en mode immersif mode. Dans De plus, Android 12 offre un comportement de rétrocompatibilité pour les applications immersive mode.
Display#getRealSize et getRealMetrics: abandon et contraintes
Les appareils Android sont disponibles dans de nombreux facteurs de forme, tels que
les écrans, les tablettes et les pliables. Afin d'afficher correctement le contenu 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. Sur Android
11, nous avons présenté le WindowMetrics
API et avons abandonné les méthodes suivantes:
Dans Android 12, nous recommandons toujours d'utiliser WindowMetrics
.
abandonnant ces méthodes:
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 pourrait avoir
un impact sur
applis 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 compatibilité plus large avec les anciennes versions d'Android, vous pouvez utiliser la
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
les tâches liées à l'interface utilisateur, notamment
WindowManager.getCurrentWindowMetrics()
ou Jetpack
WindowMetricsCalculator.computeCurrentWindowMetrics()
Si votre application crée un MediaProjection
, les limites doivent être correctement dimensionnées
car la projection capture la partition d'écran dans laquelle l'application de projecteur
est en cours d'exécution.
Si l'application est entièrement redimensionnable, le contexte de l'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 un WindowContext
.
et récupérer le WindowMetrics
des limites de l'activité à l'aide de
WindowManager.getMaximumWindowMetrics()
ou 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 est compatible avec toutes les applications en mode multifenêtre.
quelle que soit la configuration de l'application. Si
resizeableActivity="false"
,
L'application passe en mode de compatibilité si nécessaire pour s'adapter à l'affichage.
.
Sur les petits écrans (SW < 600 dp), le système vérifie l'état
minWidth
et
minHeight
pour déterminer si l'activité peut s'exécuter en mode multifenêtre. Si
resizeableActivity="false"
,
l'application ne peut pas s'exécuter en mode multifenêtre, quel que soit le nombre
la largeur et la hauteur.
Pour en savoir plus, consultez la page Compatibilité avec le mode multifenêtre.
Aperçu de l'appareil photo sur les grands écrans
Les applications d'appareil photo supposent généralement une relation fixe entre l'orientation l'appareil et le format de l'aperçu de l'appareil photo. Mais les grands écrans facteurs tels que les appareils pliables, et les modes d'affichage tels que le mode multifenêtre et le multi-écran, remettent en question cette hypothèse.
Sur Android 12, les applications d'appareil photo qui demandent un écran spécifique
et ne sont pas redimensionnables (resizeableActivity="false"
) automatiquement
passer en mode Portrait en incrustation, pour s'assurer que l'orientation et le format sont corrects.
le ratio de l'aperçu de l'appareil photo. sur les appareils pliables et les autres appareils équipés d'un appareil photo ;
la couche d'abstraction matérielle (HAL),
une rotation supplémentaire est appliquée à la sortie de la caméra pour compenser
orientation du capteur, et la sortie de l'appareil photo 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 assurent
Présentation de l'aperçu de l'appareil photo, quelle que soit l'orientation de l'appareil et qu'il soit plié
ou déplié de l'appareil.
Délai de l'expérience utilisateur pour les notifications des services de premier plan
Proposer une expérience simplifiée pour les courts de premier plan des services Google, des appareils qui exécutent Android 12 ou version ultérieure peut retarder l'affichage du service de premier plan notifications de 10 secondes, quelques-uns des exceptions. Ce le changement permet aux tâches de courte durée de s'accomplir avant que leurs notifications s'affichent.
Performances
Bucket de mise en veille des applications limité
Android 11 (niveau d'API 30) a introduit les autorisations bucket en tant que service de mise en veille des applications Bucket. À 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) : tous les buckets. Les buckets, classés par ordre de priorité (de la plus élevée à la plus basse) sont les suivants:
- Actif: l'application est en cours d'utilisation ou a été utilisée très récemment.
- Working set (Ensemble de travail) : l'application est utilisée régulièrement.
- Fréquent: l'application est souvent utilisée, mais pas tous les jours.
- Rare: l'application n'est pas souvent utilisée.
- Limité: l'application consomme beaucoup de ressources système ou peut présenter un comportement indésirable.
Le système tient compte du comportement de votre appli, en plus des schémas d'utilisation, pour décider de placer ou non votre application dans le bucket "restricted".
Votre appli est moins susceptible d'être placée dans le bucket "restricted" si elle utilise aux ressources système de manière plus responsable. De plus, le système place votre application dans un emplacement un bucket restrictif si l'utilisateur interagit directement avec votre appli.
Vérifier si votre application se trouve dans le bucket "restricted"
Pour vérifier si le système a placé votre appli 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 l'espace réservé vous pouvez déplacer manuellement votre application vers ce bucket. Pour ce faire, exécutez la commande dans une fenêtre de terminal:
adb shell am set-standby-bucket PACKAGE_NAME restricted
Sécurité et confidentialité
Position approximative
Sur les appareils équipés d'Android 12 ou version ultérieure, les utilisateurs peuvent que votre application dispose Accès uniquement à la position approximative des informations.
Si votre application demande
ACCESS_FINE_LOCATION
l'autorisation d'exécution, vous devez également demander
ACCESS_COARSE_LOCATION
autorisation de gérer le cas où l'utilisateur accorde un accès à la position approximative
à votre application. Vous devez inclure les deux autorisations dans un seul environnement d'exécution
requête.
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 localisation précises.
- Approximative: permet d'accéder uniquement à des informations de position approximatives.
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 de activer et 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. Les utilisateurs peuvent accéder aux options Réglages rapides, comme indiqué dans figure 1 ou sur l'écran Confidentialité des paramètres système.
En savoir plus
, et comment les vérifier
que votre application respecte les bonnes pratiques
CAMERA
et
RECORD_AUDIO
autorisations.
Indicateurs du micro et de 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.
En savoir plus
indicateurs clés et comment
vérifiez que votre application respecte les bonnes pratiques
CAMERA
et
RECORD_AUDIO
autorisations.
Visibilité du package 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 du package de l'application. visibilité dans d'autres applications:
Implémentation de BouncyCastle supprimée
Android 12 supprime de nombreux BouncyCastle algorithmes cryptographiques obsolètes, y compris tous les algorithmes AES algorithmes. Le système utilise à la place les implémentations Conscrypt de ces algorithmes.
Ce changement a une incidence sur votre application si l'une des conditions suivantes est remplie:
- Votre application utilise des tailles de clé de 512 bits. Conscrypt n'est pas compatible avec cette taille de clé. Si nécessaire, mettez à jour la logique de chiffrement 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 Conscrypt deKeyGenerator
effectue des opérations supplémentaires sur des paramètres clés par rapport à BouncyCastle. Par exemple, Conscrypt n'autorise pas votre application à générer une clé AES 64 bits, car AES ne prend en charge clés de 128, 192 et 256 bits.BouncyCastle autorise la génération de clés dont la taille n'est pas valide, 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 Galois/Counter Mode (GCM) à l'aide d'une taille de plus de 12 octets. l'implémentation de Conscrypt de
GcmParameterSpec
nécessite un une initialisation de 12 octets recommandée 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 sur les extraits depuis
dans l'application pour la première fois, un toast
informe l'utilisateur de l'accès au presse-papiers.
Le texte contenu dans le toast est au format suivant:
APP pasted from your clipboard.
Informations sur le texte dans la description de l'extrait
Sur Android 12 ou version ultérieure, getPrimaryClipDescription()
peut
détecter les détails suivants:
- Texte stylisé avec
isStyledText()
- les différentes classifications de texte, telles que les URL, à l'aide de
getConfidenceScore()
Les applis ne peuvent pas fermer les boîtes de dialogue système
Pour améliorer le contrôle utilisateur lorsqu'il interagit avec les applications et le système, le
ACTION_CLOSE_SYSTEM_DIALOGS
l'action d'intent est obsolète depuis Android 12. À l'exception de quelques
des cas particuliers, lorsque votre application tente d'appeler
un intent contenant cette action,
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,
SecurityException
se produit. Si votre application cible Android 11 (niveau d'API 30) ou une version antérieure, l'intent ne exécuter, et le message suivant apparaît 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 sur Android 12 ou version ultérieure:
- Votre application exécute une instrumentation test.
Votre application cible Android 11 ou une version antérieure et affiche une fenêtre. qui se trouve en haut de l'écran de notification panneau de navigation.
Votre application cible Android 11 ou une version antérieure. En outre, l'utilisateur a interagi avec une notification, par exemple à l'aide de l'action associée ; boutons, et votre application le traitement d'un service ou d'une diffusion "receiver" en réponse à cette action de l'utilisateur.
Votre application cible Android 11 ou une version antérieure, et dispose d'un service d'accessibilité. Si votre application cible Android 12 et souhaite fermer la barre de notification, utiliser la
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE
l'action d'accessibilité.
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 données tactiles des événements où une superposition masque l'application de manière dangereuse. En d'autres termes, le système bloque les touches qui passent par certaines fenêtres, à quelques exceptions.
Applications concernées
Ce changement concerne les applications qui choisissent de laisser passer des gestes dans leur fenêtre.
par exemple en utilisant
FLAG_NOT_TOUCHABLE
. Voici quelques exemples (liste non exhaustive) :
- Les superpositions nécessitant
SYSTEM_ALERT_WINDOW
autorisation, comme les fenêtres qui utilisentTYPE_APPLICATION_OVERLAY
, et utiliser l'indicateurFLAG_NOT_TOUCHABLE
. - Fenêtres d'activité qui utilisent l'indicateur
FLAG_NOT_TOUCHABLE
Exceptions
Dans les cas suivants, "pass-through" vous autorisez les pressions:
- Interactions au sein de votre application : votre application affiche la superposition, qui s'affiche en superposition. apparaît uniquement lorsque l'utilisateur interagit avec votre application.
Fenêtres de confiance : (liste non exhaustive) : suivantes:
Fenêtres invisibles La vue racine de la fenêtre est
GONE
ouINVISIBLE
Des fenêtres totalement transparentes : La Propriété
alpha
est de 0,0 pour la fenêtre.Fenêtres d'alerte système suffisamment translucides. Le système considère qu'un ensemble des fenêtres d'alerte système doivent être suffisamment transparentes lorsque l'opacité combinée est inférieure ou égale à l'opacité de masquage maximale du système pour les gestes Sous Android 12, cette opacité maximale est de 0,8 par défaut.
Détecter si une interaction non fiable est bloquée
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 la modification
Les éléments tactiles non approuvés sont bloqués par défaut sur les appareils exécutant Android 12 ou version ultérieure Pour autoriser les gestes non approuvés, 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 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 lorsque l'utilisateur appuie sur le bouton Retour
Android 12 modifie le traitement par défaut de l'appui sur le bouton Retour du système sur le lanceur d'applications activités qui sont à la base de leurs tâches. Dans les versions précédentes, le système arrêterait ces activités en appuyant sur le bouton Retour. Sous Android 12, le système se déplace l'activité et sa tâche en arrière-plan au lieu de terminer l'activité. Le nouveau comportement correspond au comportement actuel lorsque l'utilisateur quitte une application à l'aide du bouton Accueil ou d'un geste.
Pour la plupart des applications, ce changement signifie que les utilisateurs qui utilisent "Retour" pour quitter votre applications peuvent reprendre plus rapidement leur application à l'état tiède, au lieu de devoir redémarrer complètement l'application à partir d'un l'état froid.
Nous vous recommandons de tester vos applications avec ce changement. Si votre application remplace actuellement
onBackPressed()
à gérer
Revenir en arrière et terminer le Activity
, mettre à jour votre implémentation pour appeler
jusqu'à super.onBackPressed()
au lieu de terminer. Appel en cours
super.onBackPressed()
déplace l'activité et sa tâche en arrière-plan lorsque
appropriée et fournit une expérience de navigation plus cohérente aux utilisateurs
entre les applications.
Notez également qu'en général, nous vous recommandons d'utiliser les API AndroidX Activity pour
Fournir un retour arrière personnalisé
au lieu de remplacer onBackPressed()
. API AndroidX Activity
appliquer automatiquement le comportement système approprié en l'absence de
les composants qui interceptent l'appui
sur Retour du système.
Graphiques et images
Changement de fréquence d'actualisation amélioré
Sous Android 12, la fréquence d'actualisation change
setFrameRate()
peut se produire, que l'écran offre ou non une transition fluide vers
la nouvelle fréquence d'actualisation. une transition fluide est une transition qui n'a pas
des interruptions, comme un écran noir pendant une seconde ou deux. Auparavant, si le
n'offrait 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
pour savoir si la transition vers la nouvelle version se fera sans heurts 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
connectés en externe, elle est appelée lors d'une transition 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é
Informations sur Passpoint
Les API suivantes sont ajoutées à Android 12:
isPasspointTermsAndConditionsSupported()
: Les Conditions d'utilisation sont un Passpoint. qui permet aux déploiements réseau de remplacer les portails captifs non sécurisés, qui utilisent des réseaux ouverts, avec un réseau Passpoint sécurisé. Une notification est affiché à l'utilisateur lorsqu'il est nécessaire d'accepter les conditions d'utilisation. Applis qui suggèrent des réseaux Passpoint restreints par des conditions d'utilisation doit 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 autre réseau ou un ancien réseau doit être suggéré.isDecoratedIdentitySupported()
: Lors de l'authentification auprès de réseaux avec une décoration de préfixe, le le préfixe d'identité permet aux opérateurs réseau de mettre à jour Identifiant (NAI) permettant d'effectuer un routage explicite via plusieurs proxys à l'intérieur d'un réseau AAA (voir RFC 7542 pour plus d'informations à ce sujet).Android 12 implémente cette fonctionnalité conformément à la spécification WBA pour PPS-MO extensions. Les applications qui suggèrent des réseaux Passpoint nécessitant une identité décorée doivent appelez d'abord cette API pour vérifier 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 le
PasspointConfiguration
,
Credential
HomeSp
cours. Ces
décrivent le profil Passpoint, défini dans le contrat Wi-Fi Alliance
Passe
caractéristiques.
Pour en savoir plus, consultez API Wi-Fi Suggestion pour la connectivité Internet.
Mise à jour des restrictions d'interface 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.