Buckets App Standby

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 applis et de leurs dernières utilisations. En fonction des utilisations, chaque appli est placée dans l'un des cinq buckets prioritaires. Le système limite les ressources de l'appareil disponibles pour chaque appli en fonction du bucket dans lequel elles se trouvent.

Buckets prioritaires

Le système attribue dynamiquement chaque appli à un bucket prioritaire, en réaffectant les applis si nécessaire. Le système peut s'appuyer sur une appli préchargée qui exploite le machine learning pour déterminer la probabilité d'utilisation de chaque appli et attribuer des applis aux buckets appropriés.

Si l'appli système n'est pas présente sur un appareil, les paramètres système par défaut trient les applis en fonction de leur dernière utilisation. Les applis plus actives sont affectées aux buckets qui leur offrent une priorité plus élevée, ce qui leur donne accès à plus de ressources système. Plus précisément, le bucket détermine la fréquence d'exécution des tâches de l'appli et la fréquence à laquelle celle-ci peut déclencher des alarmes. Ces restrictions s'appliquent uniquement lorsque l'appareil est sur batterie. Pendant la charge, le système n'impose pas ces restrictions.

Les buckets prioritaires sont les suivants :

  • Active (Actif) : l'appli est en cours d'utilisation ou a été utilisée très récemment.
  • Working set (Ensemble de travail) : l'appli est régulièrement utilisée.
  • Frequent (Fréquent) : l'appli est souvent utilisée, mais pas quotidiennement.
  • Rare : l'appli n'est pas souvent utilisée.
  • Restrcited (Limité) : l'appli utilise beaucoup de ressources système ou peut présenter un comportement indésirable.

En plus des buckets prioritaires, il existe un bucket spécial never (jamais) pour les applis installées, mais qui ne sont jamais exécutées. Le système impose des restrictions strictes sur ces applis.

Les descriptions suivantes concernent le cas non prédictif. 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 appli récemment utilisée peut se retrouver dans le bucket rare, car le machine learning prédit qu'elle risque de ne pas être utilisée avant plusieurs heures.

Active (Actif)

Une appli se trouve dans le bucket active lorsqu'elle est utilisée, est récemment utilisée ou lorsqu'elle effectue l'une des opérations suivantes :

  • Lance une activité.
  • Exécute un service de premier plan sur le long terme.
  • L'utilisateur appuie sur une notification.

Si une appli se trouve dans le bucket "active", le système ne limite aucunement les tâches ou les alarmes de l'appli.

L'interaction de l'utilisateur attribue les applis comme actives

Sous Android 9 (niveau d'API 28) ou version ultérieure, lorsque l'utilisateur interagit avec votre appli d'une manière spécifique, le système place temporairement votre appli dans le bucket "active". Une fois que l'utilisateur n'interagit plus avec votre appli, le système la place dans un bucket en fonction de l'historique d'utilisation.

Voici des exemples d'interactions qui déclenchent ce comportement du système :

  • L'utilisateur appuie sur une notification envoyée par votre appli.

  • L'utilisateur interagit avec un service de premier plan dans votre appli en appuyant sur un bouton média.

  • L'utilisateur se connecte à votre appli lors de l'interaction avec l'Android Automotive OS, où votre appli utilise un service de premier plan ou CONNECTION_TYPE_PROJECTION.

Working set (Ensemble de travail)

Une appli se trouve dans le bucket working set si elle s'exécute souvent, mais n'est pas active. Par exemple, une appli de réseau social lancée presque quotidiennement par l'utilisateur se trouve probablement dans l'ensemble de travail. Les applis sont également promues dans le bucket "working set" si elles sont utilisées indirectement.

Si une appli 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 appli se trouve dans le bucket frequent si elle est utilisée régulièrement, mais pas nécessairement tous les jours. Par exemple, une appli de suivi de l'entraînement que l'utilisateur exécute à la salle de sport peut se trouver dans le bucket "frequent".

Si une appli 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 appli se trouve dans le bucket rare si elle n'est pas souvent utilisée. Par exemple, une appli 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 appli 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'appli à 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 appli, comme la fréquence à laquelle l'utilisateur interagit avec elle, pour décider de placer votre appli dans le bucket "restricted".

Sous Android 13 (niveau d'API 33) ou version ultérieure, sauf si votre appli remplit les conditions requises, le système la place dans le bucket "restricted" dans les cas suivants :

  • L'utilisateur n'interagit pas avec votre appli 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 le nombre de jours à 8.

  • Votre appli appelle un nombre excessif de diffusions ou de liaisons sur une période de 24 heures.

Si le système place votre appli 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 appli avec celles d'autres applis.
    • 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 appli 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 appli peut appeler une alarme par jour. Cette alarme peut être une alarme exacte ou inexacte.

Exceptions du bucket "restricted"

Les applis suivantes sont exemptées d'accès au bucket "restricted" et contournent le déclencheur d'inactivité, même sous Android 12 ou version ultérieure :

Évaluer le bucket prioritaire

Pour vérifier à quel bucket votre appli est attribué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 appli 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).

Bonnes pratiques

Si votre appli suit les bonnes pratiques pour les fonctionnalités Sommeil et Mise en veille des applications, le traitement des prochaines fonctionnalités de gestion de l'alimentation ne devrait pas poser problème. Toutefois, certains comportements d'appli qui fonctionnaient correctement auparavant peuvent désormais entraîner des problèmes.

  • N'essayez pas de manipuler le système pour placer votre appli dans un certain bucket. La méthode de définition de la priorité du système peut changer, et chaque fabricant d'appareils peut choisir d'écrire sa propre appli de binning avec son propre algorithme. Assurez-vous plutôt que votre appli se comporte de manière appropriée, quel que soit le bucket dans lequel elle se trouve.
  • Si une appli ne possède pas d'activité de lanceur d'applis, elle ne sera peut-être jamais promue au bucket actif. Envisagez de repenser votre appli pour qu'elle intègre cette activité.

  • Si les utilisateurs ne peuvent pas interagir avec les notifications de l'appli, ils ne pourront pas déclencher la promotion de l'appli dans le bucket "active". Dans ce cas, envisagez de repenser certaines notifications permettant aux utilisateurs d'interagir. Pour en savoir plus, consultez les modèles de conception des notifications Material Design.

  • Si l'appli n'affiche pas de notification à la réception d'un message Firebase Cloud Messaging (FCM) à priorité élevée, l'utilisateur ne peut pas interagir avec l'appli et donc la promouvoir vers 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 doit 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.

  • Si les applis sont réparties sur plusieurs packages, ces packages peuvent se trouver dans des buckets différents et avoir des niveaux d'accès différents. Testez ces applis avec les packages attribués à différents buckets pour vous assurer qu'elles se comportent correctement.