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:
![](https://developer.android.google.cn/static/images/about/versions/12/custom-collapsed-view.png?authuser=6&hl=fr)
![](https://developer.android.google.cn/static/images/about/versions/12/custom-expanded-view.png?authuser=6&hl=fr)
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.
Activer la modification des notifications personnalisées:
- Remplacez
targetSdkVersion
de votre application parS
pour activer le nouveau comportement. - Recompilez.
- Installez votre application sur un appareil ou un émulateur exécutant Android 12.
- Remplacez
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 utilisersetBigCustomContentView
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).
Modifications apportées à la validation Android App Links
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 l'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](https://developer.android.google.cn/static/images/toast.png?authuser=6&hl=fr)
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 commeSameSite=Lax
. - Les cookies avec
SameSite=None
doivent également spécifier l'attributSecure
, 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:
Activer manuellement les comportements SameSite sur l'appareil de test en activant/désactivant l'indicateur de l'interface utilisateur WebView-enable-modern-cookie-same-site dans les outils de développement WebView.
Cette approche vous permet d'effectuer des tests sur n'importe quel appareil équipé d'Android 5.0 (niveau d'API 21). ou version ultérieure, y compris Android 12 et WebView version 89.0.4385.0 ou supérieur.
Compilez votre application pour cibler Android 12 (niveau d'API 31) d'ici le
targetSdkVersion
.Dans ce cas, vous devez utiliser un appareil qui exécute Android 12.
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:
L'avertissement lint suivant s'affiche dans votre fichier manifeste:
When using intent filters, please specify android:exported as well
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:
- Créez un objet
PendingIntent
qui est associé à l'activité que l'utilisateur voit après avoir appuyé sur . - 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 de données.
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 la
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 mDNSResponseer 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.