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 volet des 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 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 suivants:

• Trouver ou se connecter à des appareils à proximité, comme des imprimantes ou des appareils de diffusion multimédia Ce workflow permet à votre application d'effectuer les tâches suivantes :
  • Recevoir des informations sur les points d'accès en dehors de la bande, par exemple via le BLE
  • Détectez et connectez-vous à des appareils via Wi-Fi Aware, et connectez-vous à l'aide d'un point d'accès local uniquement.
  • détecter des appareils et s'y connecter via Wi-Fi Direct ;
• Lancer une connexion à un SSID connu, comme une voiture ou un appareil connecté
• Démarrez un point d'accès local uniquement.
• Plage de portée des appareils Wi-Fi Aware à proximité.

Tant que votre application ne dérive 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 des API Wi-Fi. Lorsque vous déclarez l'autorisation NEARBY_WIFI_DEVICES, affirmez fermement que votre application ne dérive 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) ou version ultérieure 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 l'accès 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 n'envoie pas la diffusion BOOT_COMPLETED ou 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 plus riche de commandes qui sont techniquement cohérentes entre les téléphones et les tablettes, et qui correspondent é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 ce à quoi cela ressemble 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 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 en fonction de 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, ce qui entraîne une opération sans effet si la méthode est appelée.

À la place, WebView définit désormais toujours la requête multimé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 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 pu contrôler manuellement les paramètres du mode sombre.

Si vous devez toujours 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 attendu dans votre application en fonction des paramètres de targetSdkVersion et du thème.

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

• Applications de propriétaires d'appareils
• Applications de propriétaires de profils
• 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 lorsque vous ciblez Android 13 ou 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.