Comme les versions précédentes, Android 13 inclut des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 13 ou version ultérieure. Si votre application cible Android 13 ou une version ultérieure, vous devez la modifier pour prendre en charge ces comportements correctement, le cas échéant.
N'oubliez pas de consulter également la liste des modifications de comportement qui affectent toutes les applications exécutées sous Android 13.
Confidentialité
L'autorisation de notification affecte l'apparence des services de premier plan
Si l'utilisateur refuse l'autorisation de notification, les notifications liées aux services de premier plan ne s'affichent pas dans le panneau des notifications. Toutefois, les utilisateurs voient toujours les notifications liées aux services de premier plan dans le 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 l'autorisation ACCESS_FINE_LOCATION pour traiter plusieurs cas d'utilisation courants du Wi-Fi.
Comme il est difficile pour les utilisateurs d'associer les autorisations d'accéder à la position à la fonctionnalité Wi-Fi, Android 13 (niveau d'API 33) introduit une autorisation d'exécution dans le groupe d'autorisations NEARBY_DEVICES pour les applications qui gèrent les connexions d'un appareil aux points d'accès à proximité via le Wi-Fi. Cette autorisation, NEARBY_WIFI_DEVICES, répond aux 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 :
- 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 génère pas d'informations de localisation physique à partir des API Wi-Fi, demandez NEARBY_WIFI_DEVICES au lieu de ACCESS_FINE_LOCATION lorsque vous ciblez Android 13 ou une version ultérieure et utilisez les API Wi-Fi. Lorsque vous déclarez l'autorisation NEARBY_WIFI_DEVICES, affirmez fortement que votre application ne génère jamais d'informations de localisation physique à partir des API Wi-Fi. Pour ce faire, définissez l'attribut android:usesPermissionFlags sur neverForLocation. Ce processus est semblable à celui que vous effectuez sous Android 12 (niveau d'API 31) ou version ultérieure, lorsque vous affirmez que les informations de l'appareil Bluetooth ne sont jamais utilisées pour la localisation.
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 créés par d'autres applications, vous devez demander une ou plusieurs des autorisations multimédias précises suivantes au lieu de l'autorisation READ_EXTERNAL_STORAGE:
| 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 accordé les autorisations multimédias précises appropriées à 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, une seule boîte de dialogue d'autorisation système s'affiche.
Si l'autorisation READ_EXTERNAL_STORAGE a déjà été accordée à votre application, toutes les autorisations READ_MEDIA_* demandées sont accordées automatiquement lors de la mise à niveau. Vous pouvez utiliser la commande ADB suivante pour examiner les 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 d'accès "pendant l'utilisation" pour les capteurs corporels, tels que la fréquence cardiaque, la température et le pourcentage d'oxygène dans le sang. Ce modèle d'accès est très semblable à celui que le système a introduit pour la localisation dans Android 10 (niveau d'API 29).
Si votre application cible Android 13 et a besoin d'accéder aux informations des capteurs corporels lorsqu'elle s'exécute en arrière-plan, vous devez déclarer la nouvelle autorisation BODY_SENSORS_BACKGROUND en plus de l'autorisation BODY_SENSORS existante.
Performances et batterie
Utilisation des ressources de la batterie
Si l'utilisateur place votre application à l'état limité pour l'utilisation de la batterie en arrière-plan alors que votre application cible Android 13, le système ne diffuse pas la diffusion BOOT_COMPLETED ou LOCKED_BOOT_COMPLETED tant que l'application n'a pas été 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 extrait les commandes multimédias des actions PlaybackState. Cela permet au système d'afficher un ensemble plus complet de commandes qui sont techniquement cohérentes entre les téléphones et les tablettes, et qui s'alignent sur l'affichage des commandes multimédias sur d'autres plates-formes Android telles qu'Android Auto et Android TV.
La figure 2 montre à quoi cela ressemble sur un téléphone et une tablette, respectivement.
Avant Android 13, le système affichait jusqu'à cinq actions à partir de la notification MediaStyle, dans l'ordre dans lequel elles ont été ajoutées.
En mode compact (par exemple, dans les réglages rapides réduits), jusqu'à trois actions spécifiées avec setShowActionsInCompactView() étaient affichées.
À partir d'Android 13, le système affiche jusqu'à cinq boutons d'action en fonction de PlaybackState, comme décrit dans le tableau suivant. En mode compact, seuls les trois premiers emplacements d'action s'affichent. Pour les applications qui ne ciblent pas Android 13 ou celles qui n'incluent pas de PlaybackState, le système affiche des commandes basées sur la liste Action ajoutée à la notification MediaStyle, comme décrit dans le paragraphe précédent.
| Encoche | Action | Critères |
|---|---|---|
| 1 | Lire |
L'état actuel de PlaybackState est l'un des suivants :
|
| Boucle de chargement |
L'état actuel de PlaybackState est l'un des suivants :
|
|
| Suspendre | 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 à 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, la méthode setForceDark() est obsolète, ce qui entraîne une absence d'opération 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. En d'autres termes, si isLightTheme est true ou n'est pas spécifié, prefers-color-scheme est light. Sinon, il est dark. Ce comportement signifie que le style clair ou sombre du contenu Web est appliqué automatiquement pour correspondre au thème de l'application si le contenu le permet.
Pour la plupart des applications, le nouveau comportement devrait appliquer automatiquement les styles d'application appropriés. Toutefois, vous devez tester votre application pour rechercher les cas où vous auriez pu contrôler manuellement les paramètres du mode sombre.
Si vous devez toujours personnaliser le comportement du thème de couleurs de votre application, utilisez plutôt la méthode setAlgorithmicDarkeningAllowed(). Pour assurer la rétrocompatibilité avec les versions précédentes d'Android, nous vous recommandons d'utiliser la méthode setAlgorithmicDarkeningAllowed() équivalente dans AndroidX.
Consultez la documentation de cette méthode pour en savoir plus sur le comportement attendu dans votre application en fonction des paramètres targetSdkVersion et de thème de votre application.
Connectivité
Abandon de BluetoothAdapter#enable() et BluetoothAdapter#disable()
Pour les applications ciblant Android version 13 (niveau 33 d'API) ou ultérieure, les méthodes BluetoothAdapter#enable() et BluetoothAdapter#disable() sont obsolètes et renvoient toujours 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
- Applis système
Services Google Play
Autorisation requise pour l'identifiant publicitaire
Les applications qui utilisent l'identifiant publicitaire des services Google Play et ciblent Android 13 (niveau d'API 33) ou une version ultérieure doivent déclarer l'autorisation normale AD_ID dans leur 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 application ne déclare pas cette autorisation lorsqu'elle cible Android 13 ou une version ultérieure, 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 manifeste de la bibliothèque, cette autorisation est fusionnée par défaut avec le fichier manifeste de votre application. Dans ce cas, vous n'avez pas besoin de déclarer l'autorisation dans le fichier manfiest de votre application.
Pour en savoir plus, consultez Identifiant publicitaire dans l'aide de la Play Console.
Mise à jour des restrictions non SDK
Android 13 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 13, 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 13. Pour en savoir plus sur les interfaces non SDK de manière générale, consultez la section Restrictions concernant les interfaces non SDK.