Comme les versions précédentes, Android 13 inclut des modifications de comportement susceptibles d'affecter votre l'application. Les modifications de comportement suivantes ne s'appliquent qu'aux applications qui ciblent Android 13 ou version ultérieure Si votre application cible Android 13 ou une version ultérieure, vous devez modifier votre application pour prendre en charge ces comportements correctement, le cas échéant.
Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications fonctionnant sous Android 13.
Confidentialité
L'autorisation de notification affecte l'apparence des services de premier plan
Si l'utilisateur refuse les autorisation de notification, ils ne voient pas de notifications liées aux services de premier plan panneau des notifications. Toutefois, les utilisateurs voient toujours des notifications concernant les services de premier plan dans Gestionnaire de tâches, que l'autorisation de notification soit accordée ou non.
Nouvelle autorisation d'exécution pour les appareils Wi-Fi à proximité
Sur les versions précédentes d'Android, l'utilisateur doit accorder à votre application le
ACCESS_FINE_LOCATION
l’autorisation d’exécuter plusieurs cas
d’utilisation courants du Wi-Fi.
Parce qu'il est difficile pour les utilisateurs d'associer les autorisations d'accéder à la position au Wi-Fi
, Android 13 (niveau d'API 33) introduit une autorisation d'exécution dans le
NEARBY_DEVICES
groupe d'autorisations pour les applications qui gèrent les connexions d'un appareil à l'accès à proximité
points d'accès via le Wi-Fi. Cette autorisation,
NEARBY_WIFI_DEVICES,
pour les cas d'utilisation du Wi-Fi, par exemple:
- Recherchez des appareils à proximité, tels que des imprimantes ou des appareils permettant de caster des contenus multimédias, ou connectez-vous à ces appareils.
Ce workflow permet à votre application d'effectuer les tâches suivantes:
<ph type="x-smartling-placeholder">
- </ph>
- Recevoir les informations du point d'accès hors bande, par exemple via BLE
- Détectez et connectez des appareils via Wi-Fi Aware, et connectez-vous à l'aide d'un point d'accès local uniquement.
- Découvrez des appareils et connectez-vous-y via le Wi-Fi Direct.
- Établissez une connexion à un SSID connu, comme une voiture ou un appareil pour la maison connectée.
- Démarrer un point d'accès local uniquement
- Atteindre les appareils Wi-Fi Aware à proximité.
Tant que votre application ne peut pas obtenir d'informations de localisation physique à partir du réseau Wi-Fi
API, demandez NEARBY_WIFI_DEVICES au lieu de ACCESS_FINE_LOCATION lorsque vous
cibler Android 13 ou version ultérieure et utiliser les API Wi-Fi. Lorsque vous déclarez
l'autorisation NEARBY_WIFI_DEVICES, affirmez fortement que votre application ne
obtient des informations de localisation physique à partir des API Wi-Fi. Pour ce faire, définissez le paramètre
android:usesPermissionFlags à neverForLocation. Ce processus est
semblable à celle que vous utilisez sous Android 12 (niveau d'API 31) ou version ultérieure,
affirmer que les informations de l’appareil Bluetooth ne sont jamais utilisées pour
emplacement.
Découvrez comment demander l'autorisation d'accéder aux appareils Wi-Fi à proximité.
Autorisations multimédias précises
READ_MEDIA_AUDIO.Si votre application cible Android 13 ou une version ultérieure et doit
accéder aux fichiers multimédias d'autres applications
créé, vous devez
demander une ou plusieurs des autorisations multimédias précises suivantes au lieu des autorisations
READ_EXTERNAL_STORAGE
autorisation:
| Type de support | Autorisation de demander |
|---|---|
| Images et photos | READ_MEDIA_IMAGES |
| Vidéos | READ_MEDIA_VIDEO |
| Fichiers audio | READ_MEDIA_AUDIO |
Avant d'accéder aux fichiers multimédias d'une autre application, vérifiez que l'utilisateur a autorisé les autorisations multimédias précises appropriées pour votre application.
La figure 1 montre une application qui demande l'autorisation READ_MEDIA_AUDIO.
Si vous demandez à la fois l'autorisation READ_MEDIA_IMAGES et l'autorisation
READ_MEDIA_VIDEO autorisation à la fois, une seule autorisation système
s'affiche.
Si votre application a déjà reçu le rôle
READ_EXTERNAL_STORAGE
toutes les autorisations READ_MEDIA_* demandées sont alors accordées
automatiquement lors de la mise à niveau. Vous pouvez utiliser la commande ADB suivante pour examiner
autorisations mises à niveau:
adb shell cmd appops get --uid PACKAGE_NAME
L'utilisation des capteurs corporels en arrière-plan nécessite une nouvelle autorisation
Android 13 introduit le concept de "pendant l'utilisation" accès pour les capteurs corporels, comme la fréquence cardiaque, la température et le pourcentage d'oxygène dans le sang ; Ce d'accès est très semblable à celui que le système a introduit pour l'emplacement sous Android 10 (niveau d'API 29).
Si votre application cible Android 13 et a besoin d'accéder au capteur corporel
des données pendant l'exécution en arrière-plan, vous devez déclarer le nouveau
BODY_SENSORS_BACKGROUND
en plus des autorisations existantes
BODY_SENSORS
l'autorisation.
Performances et batterie
Utilisation des ressources de la batterie
Si l'utilisateur place votre application dans
"restreint" pour
utilisation de la batterie en arrière-plan
alors que votre application cible Android 13, le système ne fournit pas
une diffusion BOOT_COMPLETED ou LOCKED_BOOT_COMPLETED jusqu'au
votre application est lancée pour d'autres raisons.
Expérience utilisateur
Commandes multimédias issues de PlaybackState
Pour les applications ciblant Android 13 (niveau d'API 33) ou version ultérieure, le système obtient
commandes multimédias de
Actions PlaybackState. Ce
permet au système d'afficher un ensemble plus complet de contrôles techniquement
sont cohérentes entre les téléphones et les tablettes, et s'alignent sur la façon
les commandes sont affichées sur d'autres plates-formes Android, comme Android Auto et
Android TV
La figure 2 illustre ce à quoi cela ressemble sur un téléphone et une tablette. respectivement.
<ph type="x-smartling-placeholder">
Avant Android 13, le système affichait jusqu'à cinq actions de MediaStyle
dans l'ordre de leur ajout.
En mode compact (par exemple, dans les réglages rapides réduits), jusqu'à
Trois actions spécifiées avec setShowActionsInCompactView()
ont été diffusées.
À partir d'Android 13, le système affiche jusqu'à cinq boutons d'action en fonction
sur PlaybackState, comme décrit dans le tableau suivant. En mode compact, seuls les trois premiers
des espaces d'action s'affichent. Pour les applications qui ne ciblent pas Android 13 ou celles-ci
qui n'incluent pas de PlaybackState, le système affichera les commandes basées sur
la liste Action ajoutée à la notification MediaStyle, comme décrit dans
paragraphe précédent.
| Encoche | Action | Critères |
|---|---|---|
| 1 | Lire |
L'état actuel de PlaybackState est l'un des suivants:
<ph type="x-smartling-placeholder">
|
| Boucle de chargement |
L'état actuel de PlaybackState est l'un des suivants:
<ph type="x-smartling-placeholder">
|
|
| Mettre en pause | L'état actuel de PlaybackState n'est aucun des éléments ci-dessus. |
|
| 2 | Précédent | Les actions PlaybackState incluent ACTION_SKIP_TO_PREVIOUS. |
| Personnalisé | Les actions PlaybackState n'incluent pas les actions personnalisées ACTION_SKIP_TO_PREVIOUS et PlaybackState, qui incluent une action personnalisée qui n'a pas encore été placée. |
|
| Vide | Les extras PlaybackState incluent une valeur booléenne true pour la clé SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Suivant | Les actions PlaybackState incluent ACTION_SKIP_TO_NEXT. |
| Personnalisé | Les actions PlaybackState n'incluent pas les actions personnalisées ACTION_SKIP_TO_NEXT et PlaybackState, qui incluent une action personnalisée qui n'a pas encore été placée. |
|
| Vide | Les extras PlaybackState incluent une valeur booléenne true pour la clé SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Personnalisé | Les actions personnalisées PlaybackState incluent une action personnalisée qui n'a pas encore été placée. |
| 5 | Personnalisé | Les actions personnalisées PlaybackState incluent une action personnalisée qui n'a pas encore été placée. |
Les actions personnalisées sont placées dans l'ordre dans lequel elles ont été ajoutées au
PlaybackState
Thème de couleurs de l'application appliqué automatiquement au contenu WebView
Pour les applications ciblant Android 13 (niveau d'API 33) ou version ultérieure, le paramètre
setForceDark()
est obsolète. Par conséquent, une opération no-op est renvoyée si elle est appelée.
À la place, WebView définit désormais toujours
la requête média prefers-color-scheme en fonction de l'attribut de thème de l'application ;
isLightTheme Dans d'autres
mots, si isLightTheme est true ou n'est pas spécifié, prefers-color-scheme est
light; sinon elle est dark. Ce comportement signifie que le contenu Web
un style clair ou sombre est appliqué automatiquement pour correspondre au thème de l'application si le
le prennent en charge.
Pour la plupart des applications, le nouveau comportement devrait appliquer les styles d'application appropriés automatiquement, mais vous devez tester votre application pour vérifier s'il existe contrôlait peut-être manuellement les paramètres du mode sombre.
Si vous devez toujours personnaliser le comportement du thème de couleurs de votre application, utilisez la
setAlgorithmicDarkeningAllowed()
. Pour assurer la rétrocompatibilité avec les versions précédentes d'Android, nous
nous vous recommandons d'utiliser
setAlgorithmicDarkeningAllowed()
dans AndroidX.
Consultez la documentation de cette méthode pour en savoir plus sur le comportement que vous pouvez
s'attendent à ce que votre application
targetSdkVersion et thème
paramètres.
Connectivité
Abandon de BluetoothAdapter#enable() et BluetoothAdapter#disable()
Pour les applications ciblant Android 13 (niveau d'API 33) ou version ultérieure, le paramètre
BluetoothAdapter#enable() et
Les méthodes BluetoothAdapter#disable() sont obsolètes et toujours
renvoie false.
Les types d'applications suivants ne sont pas concernés par ces modifications:
- Applis du propriétaire de l'appareil
- Applications de propriétaire de profil
- Applications système
Services Google Play
Autorisation requise pour l'identifiant publicitaire
Les applications qui utilisent la publicité des services Google Play
ID et
Android 13 (niveau d'API 33) ou version ultérieure cible doit
déclarer l'autorisation normale AD_ID dans le fichier
fichier manifeste, comme suit:
<manifest ...>
<!-- Required only if your app targets Android 13 or higher. -->
<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>
<application ...>
...
</application>
</manifest>
Si votre appli ne déclare pas cette autorisation lorsqu'elle cible Android 13 ou supérieur, l'identifiant publicitaire est automatiquement supprimé et remplacé par une chaîne de zéros.
Si votre application utilise des SDK qui déclarent l'autorisation AD_ID dans le fichier
l'autorisation est fusionnée avec le fichier manifeste de votre application
par défaut. Dans ce cas, vous n'avez pas besoin de déclarer l'autorisation dans le fichier
.manfiest.
Pour en savoir plus, consultez la section Publicité ID dans l'aide de la Play Console.
Mise à jour des restrictions non SDK
Android 13 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 13, certaines de ces modifications pourrait ne pas vous affecter 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 la section Mises à jour de Restrictions d'interface non SDK dans Android 13 Pour en savoir plus sur les interfaces non SDK en général, consultez Restrictions concernant les interfaces non SDK. interfaces Google Cloud.