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

Comme les versions précédentes, Android 13 apporte des modifications de comportement pouvant 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 sur Android 13.

Confidentialité

L'autorisation de notification affecte l'apparence du service de premier plan

Si l'utilisateur refuse l'autorisation de notification, il ne voit pas les notifications liées aux services de premier plan dans le panneau de notifications. Toutefois, les utilisateurs voient toujours des notifications liées aux services de premier plan dans le Gestionnaire des 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 Wi-Fi courants.

Étant donné qu'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, tels que les suivants :

• Trouver des appareils à proximité (imprimantes ou appareils de diffusion de contenu multimédia, par exemple) ou s'y connecter Ce workflow permet à votre application d'accomplir les types de tâches suivants :
  • Recevez les informations sur le point d'accès hors bande, par exemple via BLE.
  • Découvrez les appareils et connectez-vous à ceux-ci via Wi-Fi Aware, puis connectez-vous à l'aide d'un point d'accès local uniquement.
  • Découvrez les appareils et connectez-vous à eux via Wi-Fi Direct.
• Établissez une connexion à un SSID connu, comme celui d'une voiture ou d'un appareil connecté.
• Démarrez un point d'accès local uniquement.
• Portée des appareils Wi-Fi Aware à proximité.

Tant que votre application ne déduit 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 version ultérieure et que vous utilisez les API Wi-Fi. Lorsque vous déclarez l'autorisation NEARBY_WIFI_DEVICES, affirmez fermement que votre application ne déduit 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 dans Android 12 (niveau d'API 31) et versions ultérieures lorsque vous affirmez que les informations sur les appareils 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

Si votre application cible Android 13 ou 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 :

Avant d'accéder aux fichiers multimédias d'une autre application, vérifiez que l'utilisateur a accordé à votre application les autorisations multimédias précises appropriées.

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 nécessite 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 existante BODY_SENSORS.

Performances et batterie

Utilisation des ressources de la batterie

Si l'utilisateur définit 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 n'envoie pas la diffusion BOOT_COMPLETED ni la diffusion LOCKED_BOOT_COMPLETED tant que l'application n'est pas démarrée pour d'autres raisons.

Expérience utilisateur

Commandes multimédias dérivées de PlaybackState

Pour les applications ciblant Android 13 (niveau d'API 33) ou version ultérieure, le système dérive les commandes multimédias des actions PlaybackState. Cela permet au système d'afficher un ensemble de commandes plus riche, techniquement cohérent entre les téléphones et les tablettes, et qui correspond également à 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 un exemple de rendu sur un téléphone et une tablette, respectivement.

Avant Android 13, le système affichait jusqu'à cinq actions de la notification MediaStyle dans l'ordre dans lequel elles avaient é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 affichera des commandes basées sur la liste Action ajoutée à la notification MediaStyle, comme décrit dans le paragraphe précédent.

Les actions personnalisées sont placées dans l'ordre dans lequel elles ont été ajoutées à 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 et n'a aucun effet si elle est appelée.

Au lieu de cela, 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 prend en charge.

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 s'il existe des cas où vous avez peut-être contrôlé manuellement les paramètres du mode sombre.

Si vous devez encore personnaliser le comportement du thème de couleur 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 auquel vous pouvez vous attendre dans votre application en fonction de ses paramètres targetSdkVersion et de thème.

Connectivité

Obsolescence de BluetoothAdapter#enable() et BluetoothAdapter#disable()

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 types d'applications suivants sont exemptés de ces modifications :

• Applications de propriétaires d'appareils
• Applications du propriétaire du profil
• Applications 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 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 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, 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 manifeste 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 en général, consultez Restrictions concernant les interfaces non SDK.