La plate-forme Android 12 apporte des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sur Android 12, peu importe 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 d'étirement du défilement hors limites
Sur les appareils équipés d'Android 12 ou version ultérieure, le comportement visuel des événements de dépassement de défilement change.
Sur Android 11 et versions antérieures, un événement de dépassement de défilement provoque une lueur 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 ils sont lancés et rebondissent lors d'un événement de balayage.
Pour en savoir plus, consultez le guide sur l'animation des gestes de défilement.
Écrans de démarrage des applications
Si vous avez déjà implémenté un écran de démarrage personnalisé dans 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, l'expérience de lancement de l'application sera dégradée ou inattendue.
Pour obtenir des instructions, consultez Migrer votre implémentation d'écran de démarrage existante 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 lors des démarrages à froid et des démarrages à chaud pour toutes les applications.
Par défaut, cet écran de démarrage système est construit à l'aide de l'élément d'icône du lanceur d'applications de votre application et de la windowBackground
de votre thème (s'il s'agit d'une couleur unique).
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), une intention Web générique n'est résolue en activité dans votre application que si celle-ci est approuvée pour le domaine spécifique contenu dans cette intention Web. Si votre application n'est pas approuvée pour le domaine, l'intent Web est résolu dans l'application de navigateur par défaut de l'utilisateur.
Les applications peuvent obtenir cette approbation en procédant de l'une des manières suivantes :
Validez le domaine à l'aide des liens d'application Android.
Pour les applications ciblant Android 12 ou version ultérieure, le système modifie la façon dont il valide automatiquement les liens d'application Android de votre application. Dans les filtres d'intent de votre application, vérifiez que vous incluez la catégorie
BROWSABLE
et que vous êtes compatible avec le schémahttps
.Sur Android 12 ou version ultérieure, vous pouvez valider manuellement les liens d'application Android de votre application pour tester l'impact de cette logique mise à jour sur votre 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 d'exécuter plus facilement des commandes de navigation par gestes en mode immersif. De plus, Android 12 fournit un comportement de rétrocompatibilité pour le mode immersif permanent.
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 appareils pliables. Pour afficher le contenu de manière appropriée sur 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 rendu obsolètes les méthodes suivantes :
Dans Android 12, nous continuons de recommander l'utilisation de 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 compatibilité plus large 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) et versions ultérieures.
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 tout travail lié à 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 projection est en cours d'exécution.
Si l'application est entièrement redimensionnable, le contexte d'activité renvoie les limites correctes 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 d'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 applications 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 la configuration. Si resizeableActivity="false"
, l'application passe en mode de compatibilité si nécessaire pour s'adapter aux dimensions de l'écran.
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 resizeableActivity="false"
, l'application n'est pas autorisée à 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 les grands écrans
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. Cependant, les facteurs de forme à grand écran, tels que les appareils pliables, et les modes d'affichage tels que le mode multifenêtre et le mode multiécran, remettent en question cette hypothèse.
Sur Android 12, les applications d'appareil photo qui demandent une orientation d'écran spécifique et qui ne sont pas redimensionnables (resizeableActivity="false"
) passent automatiquement en mode portrait avec encart, ce qui garantit l'orientation et le format 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) pour l'appareil photo, une rotation supplémentaire est appliquée à la sortie de l'appareil photo pour compenser l'orientation du capteur de l'appareil photo. 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 garantissent une présentation correcte de l'aperçu de l'appareil photo, quelle que soit l'orientation de l'appareil et qu'il soit plié ou déplié.
Délai de l'expérience utilisateur pour les notifications de service de premier plan
Pour offrir une expérience simplifiée aux services de premier plan de courte durée, les appareils exécutant Android 12 ou version ultérieure peuvent retarder l'affichage des notifications de service de premier plan de 10 secondes, avec quelques exceptions. Ce changement permet aux tâches de courte durée de se terminer 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 "Restreint" présente la priorité la plus basse (et les restrictions les plus élevées) de tous les buckets. Voici les buckets par ordre de priorité, du plus élevé au plus faible :
- Active : l'application est en cours d'utilisation ou a été utilisée récemment.
- Ensemble de travail : l'application est régulièrement utilisée.
- Fréquent : l'application est souvent utilisée, mais pas tous les jours.
- Rare : l'application n'est pas souvent utilisée.
- Restricted (Limité) : l'application utilise beaucoup de ressources système ou peut présenter un comportement indésirable.
Le système tient compte du comportement de votre application, en plus des habitudes d'utilisation, pour décider de la placer ou non 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. De plus, le système place votre application dans un bucket moins limité si l'utilisateur interagit directement avec elle.
Vérifier si votre application 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
Localisation au premier plan et économiseur de batterie
À partir d'Android 12, la localisation au premier plan (y compris à partir d'un service de premier plan) peut continuer à être fournie lorsque l'économiseur de batterie est actif, même lorsque l'écran est éteint.
Auparavant, le mode Économiseur de batterie arrêtait les mises à jour de localisation lorsque l'écran était éteint. Ce changement permet aux utilisateurs de bénéficier d'une meilleure autonomie de la batterie et signifie que les développeurs peuvent s'abstenir de demander aux utilisateurs de désactiver l'économiseur de batterie pour s'assurer que la localisation est fournie.
Les applications qui demandent la localisation via un service de premier plan doivent procéder comme suit :
- Appelez
getLocationPowerSaverMode()
pour vérifier le comportement des fonctionnalités de localisation de l'appareil lorsque l'économiseur de batterie est actif. - Si la valeur renvoyée est
LOCATION_MODE_FOREGROUND_ONLY
, votre application continuera de recevoir des mises à jour de localisation lorsqu'elle sera au premier plan ou qu'elle exécutera un service de premier plan lorsque l'économiseur de batterie sera activé et l'écran éteint.
Sécurité et confidentialité
Position approximative
Sur les appareils équipés d'Android 12 ou version ultérieure, les utilisateurs peuvent demander que votre application n'ait accès qu'aux informations de position approximative.
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 à votre application l'accès à sa position approximative. Vous devez inclure les deux autorisations dans une seule demande d'exécution.
La boîte de dialogue des autorisations système propose les options suivantes à l'utilisateur, comme illustré dans la figure 1 :
- Exacte : permet d'accéder à des informations de position exactes.
- Approximative : permet d'accéder uniquement aux informations de localisation approximatives.
Activation/Désactivation du micro et de la caméra
Sur les appareils compatibles équipés d'Android 12 ou version ultérieure, les utilisateurs peuvent activer et désactiver l'accès à la caméra et au micro pour toutes les applications installées en appuyant simplement sur un bouton. Les utilisateurs peuvent accéder aux options d'activation/de désactivation à partir des Réglages rapides, comme illustré à la figure 1, ou à partir de l'écran "Confidentialité" des paramètres système.
En savoir plus sur ces boutons bascule et sur la façon de vérifier que votre application respecte les bonnes pratiques concernant les autorisations CAMERA
et RECORD_AUDIO
.
Indicateurs de micro et de caméra
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 sur ces indicateurs et sur la façon de vérifier que votre application respecte les bonnes pratiques concernant les autorisations CAMERA
et RECORD_AUDIO
.
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és, en fonction de la visibilité des packages de l'application dans les autres applications :
Implémentation BouncyCastle supprimée
Android 12 supprime de nombreuses implémentations BouncyCastle d'algorithmes cryptographiques qui étaient auparavant obsolètes, y compris tous les algorithmes AES. Le système utilise plutôt les implémentations Conscrypt de ces algorithmes.
Cette modification affecte 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és.
Votre application utilise des tailles de clés non valides avec
KeyGenerator
. L'implémentationKeyGenerator
de Conscrypt effectue une validation supplémentaire 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 que les clés 128, 192 et 256 bits.BouncyCastle permet de générer des clés de taille non valide, mais échoue par la suite si ces clés sont utilisées avec un
Cipher
. Conscrypt échoue plus tôt.Vous initialisez vos chiffrements Galois/Counter Mode (GCM) avec une taille autre que 12 octets. L'implémentation de
GcmParameterSpec
par Conscrypt nécessite une initialisation de 12 octets, ce que recommande le NIST.
Notifications d'accès au presse-papiers
Sur Android 12 et les versions ultérieures, lorsqu'une application appelle getPrimaryClip()
pour accéder aux données du presse-papiers d'une autre application pour la première fois, un message toast informe l'utilisateur de cet accès au presse-papiers.
Le texte du message toast est au format suivant :
APP pasted from your clipboard.
Informations sur le texte dans la description du clip
Sur Android 12 et versions ultérieures, getPrimaryClipDescription()
peut détecter les informations suivantes :
- Texte stylisé, à l'aide de
isStyledText()
. - Différentes classifications de texte, telles que les URL, à l'aide de
getConfidenceScore()
.
Les applications 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. À l'exception de quelques cas particuliers, lorsque votre application tente d'appeler une intention 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 version ultérieure, une erreur
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 une version antérieure et affiche une fenêtre au-dessus du panneau de notifications.
Votre application cible Android 11 ou une version antérieure. De plus, l'utilisateur a interagi avec une notification, peut-être en utilisant les 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 fiables sont bloqués
Pour préserver la sécurité du système et offrir 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, le système bloque les événements tactiles qui traversent certaines fenêtres, à quelques exceptions près.
Applications concernées
Cette modification affecte les applications qui choisissent de laisser passer les événements tactiles à travers leurs fenêtres, par exemple en utilisant l'indicateur FLAG_NOT_TOUCHABLE
. Voici quelques exemples (liste non exhaustive) :
- Superpositions nécessitant l'autorisation
SYSTEM_ALERT_WINDOW
, telles que les fenêtres utilisantTYPE_APPLICATION_OVERLAY
, et utilisant l'indicateurFLAG_NOT_TOUCHABLE
. - Fenêtres d'activité qui utilisent l'option
FLAG_NOT_TOUCHABLE
.
Exceptions
Les cas suivants autorisent les événements tactiles "pass-through" :
- Interactions dans votre application : votre application affiche l'overlay uniquement lorsque l'utilisateur interagit avec elle.
Fenêtres approuvées : Voici quelques exemples de ces fenêtres :
Fenêtres invisibles : La vue racine de la fenêtre est
GONE
ouINVISIBLE
.Fenêtres entièrement transparentes La propriété
alpha
est définie sur 0,0 pour la fenêtre.Fenêtres d'alerte système suffisamment translucides. 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 événements tactiles. Dans Android 12, cette opacité maximale est de 0,8 par défaut.
Détecter quand une interaction tactile non approuvée 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 contacts non fiables sont bloqués par défaut sur les appareils équipés d'Android 12 ou version ultérieure. Pour autoriser les événements 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 événements tactiles non fiables 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 se terminent plus lorsque l'on appuie sur le bouton "Retour"
Android 12 modifie la gestion par défaut de la pression sur le bouton Retour du système sur les activités du lanceur qui sont à la racine de leurs tâches. Dans les versions précédentes, le système terminait ces activités lorsque l'utilisateur appuyait 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 terminer l'activité. Le nouveau comportement correspond au comportement actuel lorsque vous quittez une application à l'aide du bouton ou du geste "Accueil".
Pour la plupart des applications, ce changement signifie que les utilisateurs qui utilisent le bouton Retour pour quitter votre application peuvent la reprendre 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 ce changement. Si votre application remplace actuellement onBackPressed()
pour gérer la navigation à l'arrière et terminer l'activité Activity
, mettez à jour votre implémentation pour appeler super.onBackPressed()
au lieu de terminer. L'appel de super.onBackPressed()
déplace l'activité et sa tâche en arrière-plan le cas échéant, et offre aux utilisateurs une expérience de navigation plus cohérente dans les applications.
Notez également qu'en général, nous vous recommandons d'utiliser les API AndroidX Activity pour fournir une navigation Retour personnalisée plutôt que de remplacer onBackPressed()
. Les API AndroidX Activity s'en remettent automatiquement au comportement système approprié si aucun composant n'intercepte la pression sur le bouton Retour du système.
Graphiques et images
Amélioration du changement de fréquence d'actualisation
Dans Android 12, les changements de fréquence d'actualisation à l'aide de setFrameRate()
peuvent se produire, que l'écran soit compatible ou non avec 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 ou deux secondes. Auparavant, si l'écran ne prenait pas en charge 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 probablement fluide en appelant getAlternativeRefreshRates()
.
En général, 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 d'implémentation :
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()
: la fonctionnalité Conditions d'utilisation de Passpoint 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 soumis à 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. Vous devrez alors suggérer un autre réseau ou un réseau ancien.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 à l'intérieur d'un réseau AAA (pour en savoir plus, consultez la RFC 7542).Android 12 implémente cette fonctionnalité pour 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 la fonctionnalité, l'identité ne sera pas décorée et l'authentification au réseau risque d'é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 la Wi-Fi Alliance.
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 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 en général, consultez Restrictions concernant les interfaces non SDK.