Changements de comportement: applications ciblant Android 13 ou version ultérieure

Comme dans les versions précédentes, Android 13 apporte 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 qu'elle prenne en charge ces comportements, le cas échéant.

Veillez également à consulter 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, aucune notification liée aux services de premier plan ne s'affiche dans le panneau des notifications. Toutefois, les utilisateurs voient toujours des 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é

Dans les versions précédentes d'Android, l'utilisateur doit accorder à votre application l'autorisation ACCESS_FINE_LOCATION pour effectuer plusieurs cas d'utilisation courants du Wi-Fi.

Étant donné qu'il est difficile pour les utilisateurs d'associer les autorisations d'accéder à la position aux fonctionnalités 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:

  • Rechercher des appareils à proximité, tels que des imprimantes ou des appareils permettant de caster des contenus multimédias, ou s'y connecter Ce workflow permet à votre application d'effectuer les tâches suivantes :
    • Recevoir des informations sur le point d'accès hors bande, par exemple via BLE
    • Détectez des appareils, connectez-vous-y grâce au Wi-Fi Aware et connectez-vous à l'aide d'un point d'accès local.
    • Détectez des appareils et connectez-vous-y grâce au Wi-Fi Direct.
  • Connectez-vous à un SSID connu, par exemple un véhicule ou un appareil connecté.
  • Démarrez un point d'accès local uniquement.
  • Portée du signal jusqu'aux appareils Wi-Fi Aware à proximité.

Tant que votre application ne tire pas d'informations de localisation physique 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, déclarez fortement que votre application ne déduise 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 d'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

Les deux boutons de la boîte de dialogue, de haut en bas, sont "Autoriser" et "Ne pas autoriser".
Figure 1. Boîte de dialogue des autorisations système que voit l'utilisateur lorsque vous demandez l'autorisation READ_MEDIA_AUDIO.

Si votre application cible Android 13 ou une version ultérieure et doit accéder à des 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 demande
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 automatiquement accordées 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 qu'elle a besoin d'accéder aux informations du capteur corporel 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 batterie

Si l'utilisateur place votre application à l'état Limité pour utiliser la batterie en arrière-plan alors qu'elle cible Android 13, le système ne diffuse pas la diffusion BOOT_COMPLETED ou LOCKED_BOOT_COMPLETED tant que l'application n'a pas démarré 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 des commandes multimédias à partir des actions PlaybackState. Cela permet au système d'afficher un ensemble plus riche de commandes techniquement cohérentes entre les téléphones et les tablettes, et de s'aligner sur la façon dont les commandes multimédias sont affichées 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.

Affichage des commandes multimédias sur les téléphones et les tablettes, à l'aide d'un exemple de piste montrant comment les boutons peuvent s'afficher
Figure 2 : Commandes multimédias sur les téléphones et les tablettes

Avant Android 13, le système affichait jusqu'à cinq actions à partir de la notification MediaStyle dans l'ordre dans lequel elles étaient ajoutées. En mode compact (par exemple, dans les paramètres rapides réduits), jusqu'à trois actions spécifiées avec setShowActionsInCompactView() ont été 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 espaces pour les actions sont affichés. Pour les applications qui ne ciblent pas Android 13 ou celles qui n'incluent pas de PlaybackState, le système affiche des commandes en fonction de 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 la PlaybackState est l'un des suivants :
  • STATE_NONE
  • STATE_STOPPED
  • STATE_PAUSED
  • STATE_ERROR
Boucle de chargement L'état actuel de la PlaybackState est l'un des suivants :
  • STATE_CONNECTING
  • STATE_BUFFERING
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 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 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 couleur 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 no-op si la méthode est appelée.

Désormais, WebView définit 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 défini sur true ou n'est pas spécifié, prefers-color-scheme est light. Sinon, il s'agit de 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 vérifier si vous avez peut-être contrôlé manuellement les paramètres du mode sombre.

Si vous devez encore 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 du thème de votre application.

Connectivité

BluetoothAdapter#enable() et BluetoothAdapter#disable() obsolètes

Pour les applications ciblant Android 13 (niveau d'API 33) ou version ultérieure, les méthodes BluetoothAdapter#enable() et BluetoothAdapter#disable() sont obsolètes et renvoient toujours false.

Les applications suivantes ne sont pas concernées par ces modifications:

  • Applications Device Owner
  • 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 version ultérieure doivent déclarer l'autorisation normale AD_ID dans le fichier manifeste de leur application, 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 lorsque vous ciblez 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, l'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 manuel de votre application.

Pour en savoir plus, consultez la section 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 des interfaces 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.