Changements de comportement : toutes les applications

La plate-forme Android 16 apporte des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sur Android 16, peu importe la targetSdkVersion. Vous devez tester votre application, puis la modifier si nécessaire afin de prendre en charge ces modifications, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui n'affectent que les applications ciblant Android 16.

Fonctionnalité de base

Android 16 (niveau d'API 36) inclut les modifications suivantes qui modifient ou étendent diverses fonctionnalités de base du système Android.

Optimisations du quota JobScheduler

À partir d'Android 16, nous ajustons le quota d'exécution d'une tâche régulière et accélérée en fonction des facteurs suivants:

  • Dans quel bucket de veille de l'application se trouve l'application: dans Android 16, les buckets de veille actifs commenceront à être appliqués par un quota d'exécution généreux.
  • Si la tâche commence l'exécution alors que l'application est en haut de l'écran: sous Android 16, les tâches démarrées alors que l'application est visible par l'utilisateur et qui se poursuivent après que l'application est devenue invisible respectent le quota d'exécution de la tâche.
  • Si la tâche s'exécute pendant l'exécution d'un service de premier plan: dans Android 16, les tâches qui s'exécutent simultanément avec un service de premier plan respectent le quota d'exécution de la tâche. Si vous utilisez des tâches pour le transfert de données déclenché par l'utilisateur, envisagez d'utiliser plutôt des tâches de transfert de données déclenchées par l'utilisateur.

Ce changement affecte les tâches planifiées à l'aide de WorkManager, JobScheduler et DownloadManager. Pour déboguer la raison pour laquelle une tâche a été arrêtée, nous vous recommandons de consigner la raison pour laquelle votre tâche a été arrêtée en appelant WorkInfo.getStopReason() (pour les tâches JobScheduler, appelez JobParameters.getStopReason()).

Pour en savoir plus sur l'impact de l'état de votre application sur les ressources qu'elle peut utiliser, consultez la section Limites de ressources de gestion de l'alimentation. Pour en savoir plus sur les bonnes pratiques d'optimisation de la batterie, consultez les conseils sur l'optimisation de l'utilisation de la batterie pour les API de planification des tâches.

Nous vous recommandons également d'exploiter la nouvelle API JobScheduler#getPendingJobReasonsHistory introduite dans Android 16 pour comprendre pourquoi une tâche n'a pas été exécutée.

Tests

Pour tester le comportement de votre application, vous pouvez activer le forçage de certaines optimisations de quota de tâches tant que l'application s'exécute sur un appareil Android 16.

Pour désactiver l'application de la règle "L'état supérieur respectera le quota d'exécution de la tâche", exécutez la commande adb suivante:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Pour désactiver l'application de la règle "Les tâches exécutées simultanément avec un service de premier plan respectent le quota d'exécution des tâches", exécutez la commande adb suivante:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Pour tester certains comportements de bucket de mise en veille de l'application, vous pouvez définir le bucket de mise en veille de votre application à l'aide de la commande adb suivante:

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

Pour comprendre le bucket de mise en veille de votre application, vous pouvez obtenir le bucket de mise en veille de votre application à l'aide de la commande adb suivante:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motif d'arrêt des jobs vides abandonnés

Une tâche abandonnée se produit lorsque l'objet JobParameters associé à la tâche a été éliminé par la récupération de mémoire, mais que JobService#jobFinished(JobParameters, boolean) n'a pas été appelé pour signaler la fin de la tâche. Cela indique que la tâche peut être en cours d'exécution et être reprogrammée sans que l'application en soit informée.

Les applications qui s'appuient sur JobScheduler ne conservent pas de référence forte à l'objet JobParameters. Le délai avant expiration est désormais accordé avec la nouvelle raison d'arrêt de la tâche STOP_REASON_TIMEOUT_ABANDONED, au lieu de STOP_REASON_TIMEOUT.

Si la nouvelle raison d'abandon de la tâche se produit fréquemment, le système prendra des mesures d'atténuation pour réduire la fréquence des tâches.

Les applications doivent utiliser la nouvelle raison d'arrêt pour détecter et réduire les tâches abandonnées.

Si vous utilisez WorkManager, AsyncTask ou DownloadManager, vous n'êtes pas concerné, car ces API gèrent le cycle de vie des tâches pour le compte de votre application.

Abandon complet de JobInfo#setImportantWhileForeground

La méthode JobInfo.Builder#setImportantWhileForeground(boolean) indique l'importance d'une tâche lorsque l'application de planification est au premier plan ou lorsqu'elle est temporairement exemptée des restrictions en arrière-plan.

Cette méthode est obsolète depuis Android 12 (niveau d'API 31). À partir d'Android 16, elle ne fonctionne plus efficacement et l'appel de cette méthode sera ignoré.

Cette suppression de fonctionnalité s'applique également à JobInfo#isImportantWhileForeground(). À partir d'Android 16, si la méthode est appelée, elle renvoie false.

Le champ d'application de la priorité de diffusion ordonnée n'est plus global

Les applications Android sont autorisées à définir des priorités sur les broadcast receivers pour contrôler l'ordre dans lequel les broadcast receivers reçoivent et traitent la diffusion. Pour les récepteurs déclarés dans le fichier manifeste, les applications peuvent utiliser l'attribut android:priority pour définir la priorité. Pour les récepteurs enregistrés dans le contexte, les applications peuvent utiliser l'API IntentFilter#setPriority() pour définir la priorité. Lorsqu'une annonce est envoyée, le système la transmet aux destinataires par ordre de priorité, de la plus élevée à la plus basse.

Dans Android 16, l'ordre de diffusion des diffusions à l'aide de l'attribut android:priority ou IntentFilter#setPriority() dans différents processus n'est pas garanti. Les priorités de diffusion ne seront respectées que dans le même processus d'application, et non dans tous les processus.

De plus, les priorités de diffusion seront automatiquement limitées à la plage (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Seuls les composants système seront autorisés à définir SYSTEM_LOW_PRIORITY et SYSTEM_HIGH_PRIORITY comme priorité de diffusion.

Votre application peut être affectée si elle:

  1. Votre application a déclaré plusieurs processus avec le même intent de diffusion et a des attentes concernant la réception de ces intents dans un certain ordre en fonction de la priorité.
  2. Votre processus d'application interagit avec d'autres processus et a des attentes concernant la réception d'un intent de diffusion dans un certain ordre.

Si les processus doivent se coordonner entre eux, ils doivent communiquer via d'autres canaux de coordination.

Modifications internes d'ART

Android 16 inclut les dernières mises à jour d'Android Runtime (ART) qui améliorent les performances d'Android Runtime (ART) et prennent en charge des fonctionnalités Java supplémentaires. Grâce aux mises à jour du système Google Play, ces améliorations sont également disponibles pour plus d'un milliard d'appareils équipés d'Android 12 (niveau d'API 31) ou version ultérieure.

Lorsque ces modifications seront publiées, les bibliothèques et le code d'application qui s'appuient sur les structures internes d'ART risquent de ne pas fonctionner correctement sur les appareils équipés d'Android 16, ainsi que sur les versions antérieures d'Android qui mettent à jour le module ART via les mises à jour du système Google Play.

S'appuyer sur des structures internes (telles que les interfaces autres que le SDK) peut toujours entraîner des problèmes de compatibilité, mais il est particulièrement important d'éviter de s'appuyer sur du code (ou des bibliothèques contenant du code) qui exploite des structures ART internes, car les modifications ART ne sont pas liées à la version de la plate-forme sur laquelle l'appareil s'exécute et elles sont diffusées auprès de plus d'un milliard d'appareils via les mises à jour du système Google Play.

Tous les développeurs doivent vérifier si leur application est affectée en effectuant des tests approfondis sur Android 16. En outre, consultez les problèmes connus pour voir si votre application dépend de bibliothèques que nous avons identifiées comme s'appuyant sur des structures ART internes. Si vous avez des dépendances de code d'application ou de bibliothèque qui sont concernées, recherchez des alternatives d'API publiques dans la mesure du possible et demandez des API publiques pour de nouveaux cas d'utilisation en créant une demande de fonctionnalité dans notre outil Issue Tracker.

Mode de compatibilité de taille de page de 16 ko

Android 15 引入了对 16 KB 内存页面的支持，以优化平台性能。Android 16 添加了兼容模式，让一些针对 4 KB 内存页面构建的应用可以在配置为 16 KB 内存页面的设备上运行。

当您的应用在搭载 Android 16 或更高版本的设备上运行时，如果 Android 检测到您的应用具有 4 KB 对齐的内存页面，则会自动使用兼容模式并向用户显示通知对话框。在 AndroidManifest.xml 中设置 android:pageSizeCompat 属性以启用向后兼容模式，将会阻止应用启动时显示对话框。如需使用 android:pageSizeCompat 属性，请使用 Android 16 SDK 编译您的应用。

为了实现最佳性能、可靠性和稳定性，应用仍应以 16 KB 对齐。如需了解详情，请参阅我们近期发布的博文，了解如何更新应用以支持 16 KB 的内存页面。

兼容模式对话框：当系统检测到 4 KB 对齐的应用在 16 KB 对齐的情况下可以更高效地运行时，系统会显示此对话框。

Expérience utilisateur et interface utilisateur du système

Android 16 (niveau d'API 36) inclut les modifications suivantes, qui visent à créer une expérience utilisateur plus cohérente et intuitive.

Abandon des annonces d'accessibilité intrusives

Android 16 abandonne les annonces d'accessibilité, caractérisées par l'utilisation de announceForAccessibility ou l'envoi d'événements d'accessibilité TYPE_ANNOUNCEMENT. Cela peut créer des expériences utilisateur incohérentes pour les utilisateurs de TalkBack et du lecteur d'écran d'Android. Les alternatives répondent mieux à un plus large éventail de besoins des utilisateurs dans diverses technologies d'assistance d'Android.

Exemples d'alternatives:

La documentation de référence de l'API announceForAccessibility obsolète inclut plus de détails sur les alternatives suggérées.

Prise en charge de la navigation à trois boutons

Android 16 prend en charge la prévisualisation du Retour dans la navigation à trois boutons pour les applications qui ont correctement migré vers la prévisualisation du Retour. Appuyer de manière prolongée sur le bouton Retour déclenche une animation de prévisualisation du Retour, qui vous permet de prévisualiser la page vers laquelle le geste Retour vous redirige.

Ce comportement s'applique à toutes les zones du système compatibles avec les animations de prévisualisation du Retour, y compris les animations système (retour à l'écran d'accueil, multitâche et multi-activité).

Animations de prévisualisation du Retour en mode navigation à trois boutons.

Prise en charge de la navigation à trois boutons

Beginning with Android 16 QPR 2, Android automatically applies themes to app icons to create a cohesive home screen experience. This occurs if an app does not provide its own themed app icon. Apps can control the design of their themed app icon by including a monochrome layer within their adaptive icon and previewing what their app icon will look like in Android Studio.

Facteurs de forme des appareils

Android 16 (niveau d'API 36) inclut les modifications suivantes pour les applications lorsqu'elles sont projetées sur des écrans par les propriétaires d'appareils virtuels.

Remplacements du propriétaire de l'appareil virtuel

虚拟设备所有者是创建和管理虚拟设备的受信任应用或特权应用。虚拟设备所有者在虚拟设备上运行应用，然后将应用投影到远程设备的显示屏上，例如个人电脑、虚拟现实设备或车载信息娱乐系统。虚拟设备所有者位于本地设备上，例如手机。

手机上的虚拟设备所有者创建将应用投影到远程显示屏的虚拟设备。

按应用替换项

在搭载 Android 16（API 级别 36）的设备上，虚拟设备所有者可以替换其管理的特定虚拟设备上的应用设置。例如，为了改进应用布局，虚拟设备所有者在将应用投影到外部显示屏上时，可以忽略屏幕方向、宽高比和可调整大小性限制。

常见的重大更改

Android 16 行为可能会影响应用在汽车显示屏或 Chromebook 等大屏幕设备上的界面，尤其是那些专为竖屏小显示屏设计的布局。如需了解如何让应用适应所有设备类型，请参阅关于自适应布局。

参考编号

配套应用串流

Sécurité

Android 16 (niveau d'API 36) inclut des modifications qui favorisent la sécurité du système pour protéger les applications et les utilisateurs contre les applications malveillantes.

Sécurité renforcée contre les attaques par redirection d'intentions

Android 16 offre une protection par défaut contre les attaques de redirection Intentgénérales, avec un minimum de modifications requises en termes de compatibilité et de développement.

Nous introduisons des solutions de renforcement de la sécurité par défaut pour les exploits de redirection Intent. Dans la plupart des cas, les applications qui utilisent des intents ne rencontrent aucun problème de compatibilité. Nous avons collecté des métriques tout au long de notre processus de développement pour identifier les applications susceptibles de rencontrer des problèmes.

La redirection d'intent dans Android se produit lorsqu'un pirate informatique parvient à contrôler partiellement ou entièrement le contenu d'un intent utilisé pour lancer un nouveau composant dans le contexte d'une application vulnérable, tandis que l'application victime lance un intent de sous-niveau non fiable dans un champ "Extras" d'un intent ("de premier niveau"). Cela peut permettre à l'application du pirate informatique de lancer des composants privés dans le contexte de l'application victime, de déclencher des actions privilégiées ou d'obtenir un accès URI à des données sensibles, ce qui peut potentiellement entraîner un vol de données et une exécution de code arbitraire.

Désactiver la gestion de la redirection d'intent

Android 16 introduit une nouvelle API qui permet aux applications de désactiver les protections de sécurité au lancement. Cela peut être nécessaire dans des cas spécifiques où le comportement de sécurité par défaut interfère avec des cas d'utilisation légitimes de l'application.

Pour les applications compilées avec le SDK Android 16 (niveau d'API 36) ou version ultérieure

Vous pouvez utiliser directement la méthode removeLaunchSecurityProtection() sur l'objet Intent.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
Pour les applications compilées avec Android 15 (niveau d'API 35) ou version antérieure

Bien que cela ne soit pas recommandé, vous pouvez utiliser la réflexion pour accéder à la méthode removeLaunchSecurityProtection().

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

Les applications associées ne reçoivent plus de notification en cas de délai d'expiration de la découverte

Android 16 introduit un nouveau comportement lors du flux d'association d'appareils compagnons pour protéger la confidentialité de la position de l'utilisateur contre les applications malveillantes. Toutes les applications compagnons exécutées sur Android 16 ne sont plus directement informées du délai avant expiration de la découverte à l'aide de RESULT_DISCOVERY_TIMEOUT. À la place, l'utilisateur est averti des événements de délai avant expiration à l'aide d'une boîte de dialogue visuelle. Lorsque l'utilisateur ferme la boîte de dialogue, l'application est avertie de l'échec de l'association avec RESULT_USER_REJECTED.

La durée de la recherche a également été prolongée par rapport aux 20 secondes d'origine, et l'utilisateur peut arrêter la découverte des appareils à tout moment pendant la recherche. Si au moins un appareil a été détecté dans les 20 premières secondes de la recherche, le CDM cesse de rechercher d'autres appareils.

Connectivité

Android 16 (niveau d'API 36) inclut les modifications suivantes dans la pile Bluetooth pour améliorer la connectivité avec les périphériques.

Amélioration de la gestion des pertes d'obligations

Starting in Android 16, the Bluetooth stack has been updated to improve security and user experience when a remote bond loss is detected. Previously, the system would automatically remove the bond and initiate a new pairing process, which could lead to unintentional re-pairing. We have seen in many instances apps not taking care of the bond loss event in a consistent way.

To unify the experience, Android 16 improved the bond loss handling to the system. If a previously bonded Bluetooth device could not be authenticated upon reconnection, the system will disconnect the link, retain local bond information, and display a system dialog informing users of the bond loss and directing them to re-pair.