Android 9 (niveau d'API 28) ou version ultérieure est compatible avec les buckets de mise en veille des applications. Les buckets de mise en veille des applications permettent au système de hiérarchiser les demandes d'accès aux ressources en fonction de la fréquence d'utilisation des applications et de leurs dernières utilisations. En fonction des utilisations, chaque application est placée dans l'un des cinq buckets prioritaires. Le système limite les ressources de l'appareil disponibles pour chaque application en fonction du bucket dans lequel elles se trouvent.
Buckets prioritaires
Le système attribue dynamiquement chaque application à un bucket prioritaire, en réaffectant les applications si nécessaire. Le système peut s'appuyer sur une application préchargée qui exploite le machine learning pour déterminer la probabilité d'utilisation de chaque application et attribuer des applications aux buckets appropriés. Si l'application système n'est pas présente sur un appareil, le système trie par défaut les applications en fonction de leur dernière utilisation. Plus les applications sont actives, plus elles sont affectées à des buckets. Leur priorité est donc plus élevée, et l'application a ainsi plus de ressources système. Plus précisément, le bucket détermine la fréquence d'exécution des tâches de l'application et la fréquence à laquelle l'application peut déclencher des alarmes. Ces restrictions s'appliquent uniquement lorsque l'appareil est sur batterie. Le système n'impose pas ces restrictions aux applications pendant la charge de l'appareil.
Remarque : Chaque fabricant peut définir ses propres critères d'attribution d'applications inactives aux buckets. Vous ne devez pas essayer d'influencer le bucket auquel votre application est attribuée. Concentrez-vous plutôt sur le comportement de votre application, quel que soit son bucket. Votre application peut connaître le bucket dans lequel elle se trouve en appelant
UsageStatsManager.getAppStandbyBucket()
.
Les buckets sont les suivants :
- Active (Actif) : l'application est en cours d'utilisation ou a été utilisée récemment.
- Working set (Ensemble de travail) : l'application est régulièrement utilisée.
- Frequent (Fréquent) : l'application est souvent utilisée, mais pas tous les jours.
- Rare : l'application n'est pas souvent utilisée.
- Restricted (Limité) : l'application utilise beaucoup de ressources système ou peut présenter un comportement indésirable.
En outre, il existe un bucket spécial never (jamais) pour les applications qui ont été installées, mais qui n'ont jamais été exécutées. Le système impose des restrictions strictes sur ces applications.
Remarque : Les applications qui figurent sur la liste d'exception de Sommeil sont exemptées des restrictions basées sur les buckets de mise en veille des applications.
Remarque : Les descriptions ci-dessous concernent les cas non prédictifs. En revanche, lorsque la prédiction prédit le comportement via le machine learning, les buckets sont choisis de manière à anticiper les actions suivantes de l'utilisateur plutôt qu'en fonction de la dernière utilisation. Par exemple, une application récemment utilisée peut se retrouver dans le bucket rare, car le machine learning prédit qu'elle ne sera pas utilisée avant plusieurs heures.
Active (Actif)
Une application se trouve dans le bucket active si l'utilisateur est en train d'utiliser l'application ou l'a utilisée très récemment. Exemple :
- L'application a lancé une activité.
- L'application exécute un service de premier plan.
- L'application est associée à un adaptateur de synchronisation associé à un fournisseur de contenu et utilisé par une application de premier plan.
- L'utilisateur clique sur une notification de l'application.
Si une application se trouve dans le bucket "active", le système ne limite aucunement les tâches ou les alarmes de l'application.
L'interaction de l'utilisateur place les applications dans le bucket "active"
Sous Android 9 (niveau d'API 28) ou version ultérieure, lorsque l'utilisateur interagit avec votre application d'une manière spécifique, le système place temporairement votre application dans le bucket "active". Quelque temps après que l'utilisateur n'interagit plus avec votre application, le système la place dans un bucket en fonction de l'historique d'utilisation.
Voici quelques exemples d'interactions qui déclenchent ce comportement du système :
L'utilisateur appuie sur une notification envoyée par votre application.
L'utilisateur interagit avec un service de premier plan dans votre application en appuyant sur un bouton média.
L'utilisateur se connecte à votre application lors de l'interaction avec l'Android Automotive OS, où votre application utilise un service de premier plan ou
CONNECTION_TYPE_PROJECTION
.
Working set (Ensemble de travail)
Une application se trouve dans le bucket working set si elle s'exécute souvent, mais n'est pas active actuellement. Par exemple, une application de réseau social lancée le plus souvent par l'utilisateur se trouve probablement dans l'ensemble de travail. Les applications sont également promues dans le bucket "working set" si elles sont utilisées indirectement.
Si une application fait partie de l'ensemble de travail, le système impose de légères restrictions à sa capacité à exécuter des tâches et à déclencher des alarmes. Pour en savoir plus, consultez Restrictions de gestion de l'alimentation.
Frequent (Fréquent)
Une application se trouve dans le bucket frequent si elle est utilisée régulièrement, mais pas nécessairement tous les jours. Par exemple, une application de suivi de l'entraînement que l'utilisateur exécute à la salle de sport peut se trouver dans le bucket "frequent".
Si une application se trouve dans ce bucket, le système impose des restrictions plus strictes quant à sa capacité à exécuter des tâches et à déclencher des alarmes. Pour en savoir plus, consultez Restrictions de gestion de l'alimentation.
Rare
Une application se trouve dans le bucket rare si elle n'est pas souvent utilisée. Par exemple, une application d'hôtel que l'utilisateur n'exécute que lorsqu'il séjourne dans cet hôtel peut se trouver dans le bucket "rare".
Si une application se trouve dans ce bucket, le système impose des restrictions strictes quant à sa capacité à exécuter des tâches et à déclencher des alarmes. Le système limite également la capacité de l'application à se connecter à Internet. Pour en savoir plus, consultez Restrictions de gestion de l'alimentation.
Restricted (Limité)
Ce bucket, ajouté dans Android 12 (niveau d'API 31), présente la priorité la plus basse (et les restrictions les plus élevées) de tous les buckets. Le système tient compte du comportement de votre application, comme la fréquence à laquelle l'utilisateur interagit avec elle, pour décider de placer votre application dans le bucket "restricted".
Sous Android 13 (niveau d'API 33) ou version ultérieure, sauf si votre application remplit les conditions requises, le système la place dans le bucket "retricted" dans les cas suivants :
L'utilisateur n'interagit pas avec votre application pendant un certain nombre de jours. Sous Android 12 (niveau d'API 31) et 12 L (niveau d'API 32), cette durée est de 45 jours. Android 13 réduit ce nombre à 8 jours.
Votre application appelle un nombre excessif de diffusions ou de liaisons sur une période de 24 heures.
Si le système place votre application dans le bucket "restricted", les restrictions suivantes s'appliquent :
- Vous pouvez exécuter des tâches une fois par jour au cours d'une session par lot de 10 minutes. Au cours de cette session, le système regroupe les tâches de votre application avec celles d'autres applications.
- Les tâches limitées ne sont pas exécutées seules. Au moins une autre tâche doit être en cours d'exécution ou en attente, ce qui peut inclure toute autre tâche.
- Votre application ne peut pas exécuter autant de tâches accélérées que lorsque le système la place dans un bucket moins limité.
- Votre application peut appeler une alarme par jour. Cette alarme peut être une alarme exacte ou inexacte.
Exemptions d'accès au bucket "restricted"
Les applications suivantes sont exemptées d'accès au bucket de mise en veille des applications "restricted" et contournent le déclencheur d'inactivité, même sous Android 12 ou version ultérieure :
- Applications associées d'appareils
- Applications exécutées sur un appareil en mode démo
- Applications de propriétaires d'appareils
- Applications de propriétaires de profils
- Applications persistantes
- Applications de VPN
- Applications disposant du rôle
ROLE_DIALER
- Applications que l'utilisateur a explicitement désignées pour fournir une fonctionnalité "unrestricted" (sans restriction) dans les paramètres système
- Applications comportant des widgets actifs
- Applications visibles en mode Picture-in-picture
- Applications actives qui figurent à l'écran
- Applications disposant d'au moins l'une des autorisations suivantes :
Bonnes pratiques
Si votre application suit déjà les bonnes pratiques pour les fonctionnalités Sommeil et Mise en veille des applications, le traitement des nouvelles fonctionnalités de gestion de l'alimentation ne devrait pas poser problème. Toutefois, certains comportements d'application qui fonctionnaient correctement auparavant peuvent désormais entraîner des problèmes.
- N'essayez pas de manipuler le système pour placer votre application dans tel ou tel bucket. Les méthodes de binning du système peuvent changer, et les fabricants d'appareils peuvent choisir de créer leur propre application de binning avec leur algorithme propriétaire. Assurez-vous plutôt que votre application se comporte de manière appropriée, quel que soit le bucket dans lequel elle se trouve.
- Si une application ne possède pas d'activité de lanceur d'applications, elle ne sera peut-être jamais promue au bucket "active". Il faudra peut-être repenser votre application pour qu'elle intègre cette activité.
- Si les notifications ne sont pas exploitables, les utilisateurs ne pourront pas déclencher la promotion de l'application dans le bucket "active" en interagissant avec les notifications. Dans ce cas, vous pouvez modifier les notifications appropriées afin qu'elles permettent à l'utilisateur de répondre. Pour en savoir plus, consultez les modèles de conception des notifications Material Design.
- De même, si l'application n'affiche pas de notification à la réception d'un message Firebase Cloud Messaging (FCM) à priorité élevée, l'utilisateur sera dans l'impossibilité d'interagir avec l'application et de la promouvoir dans le bucket "active". La seule utilisation prévue pour les messages FCM à priorité élevée consiste à envoyer une notification à l'utilisateur. Cette situation ne devrait donc pas se produire. À partir de la version 12L (niveau d'API 32), si vous marquez de manière inappropriée un message FCM comme étant prioritaire alors qu'il ne déclenche pas d'interaction utilisateur, la priorité des futurs messages risque d'être abaissée.
Remarque : Si l'utilisateur ignore une notification à plusieurs reprises, le système lui offre la possibilité de la bloquer à l'avenir. N'envoyez pas de spam à l'utilisateur simplement pour faire en sorte que votre application soit conservée dans le bucket "active" !
- Si les applications sont réparties sur plusieurs packages, ils peuvent se trouver dans des buckets différents et donc avoir des niveaux d'accès différents. Assurez-vous de tester ces applications avec les packages attribués à différents buckets pour vous assurer qu'elles fonctionnent correctement.
Tests
Pour vérifier dans quel bucket votre application a été placée, effectuez l'une des opérations suivantes :
- Appelez
getAppStandbyBucket()
. -
Exécutez la commande suivante dans une fenêtre de terminal :
adb shell am get-standby-bucket PACKAGE_NAME
Le système limite votre application chaque fois qu'elle est placée dans un bucket de mise en veille des applications dont la valeur est supérieure à STANDBY_BUCKET_ACTIVE
(10).