Android 9 (niveau d'API 28) introduit de nouvelles fonctionnalités pour améliorer la gestion de l'alimentation des appareils. Ces modifications, ainsi que les fonctionnalités qui étaient déjà présentes dans les versions précédentes, permettent de garantir que les ressources système sont allouées aux applications qui en ont le plus besoin.
Les fonctionnalités de gestion de l'alimentation se divisent en deux catégories:
- Buckets de mise en veille des applications
- Le système limite l'accès des applications aux ressources de l'appareil telles que le processeur ou la batterie, en fonction des habitudes d'utilisation de l'utilisateur. Il s'agit d'une nouvelle fonctionnalité pour Android 9.
- Améliorations apportées à l'économiseur de batterie
- Lorsque l'économiseur de batterie est activé, le système impose des restrictions sur toutes les applications. Il s'agit d'une fonctionnalité existante améliorée avec Android 9.
Buckets App Standby
Android 9 introduit une nouvelle fonctionnalité de gestion de la batterie : les buckets App Standby. 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 date et de la fréquence d'utilisation des applications. En fonction des modèles d'utilisation des applications, 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 elle se trouve.
Ces cinq catégories hiérarchisent les applications en fonction des caractéristiques suivantes:
- Actif
Une application se trouve dans le bucket "active" si l'utilisateur est en train d'utiliser l'application, par exemple:
- L'application a lancé une activité.
- L'application exécute un service de premier plan.
- L'application dispose d'un adaptateur de synchronisation associé à un fournisseur de contenu utilisé par une application au 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, les alarmes ou les messages FCM de l'application.
- Working set (Ensemble de travail)
Une application se trouve dans le bucket de l'ensemble de travail si elle s'exécute souvent, mais qu'elle n'est pas active actuellement. Par exemple, une application de réseau social que l'utilisateur lance la plupart du temps fait probablement partie de 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 ce bucket 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 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, et impose également une limite aux messages FCM à priorité élevée. 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 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, à déclencher des alarmes et à recevoir des messages FCM à priorité élevée. Le système limite également la capacité de l'application à se connecter à Internet. Pour en savoir plus, consultez Restrictions de gestion de l'alimentation.
- Jamais
Les applis qui ont été installées, mais qui ne sont jamais exécutées sont attribuées au bucket "Jamais". Le système impose des restrictions strictes sur ces applications.
Le système attribue dynamiquement chaque application à un bucket prioritaire et réattribue les applications si nécessaire. Le système peut s'appuyer sur une application préchargée qui utilise le machine learning pour déterminer la probabilité d'utilisation de chaque application et les attribuer 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. Les applications plus actives sont affectées à des buckets qui leur accordent une priorité plus élevée, ce qui leur donne plus de ressources système. Plus spécifiquement, le bucket détermine la fréquence d'exécution des tâches de l'application, la fréquence à laquelle l'application peut déclencher des alarmes et la fréquence à laquelle l'application peut recevoir des messages Firebase Cloud Messaging (FCM) à priorité élevée. Ces restrictions ne s'appliquent que lorsque l'appareil est sur batterie. Le système n'impose pas ces restrictions aux applications pendant que l'appareil est en charge.
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 appli est attribuée. Concentrez-vous plutôt sur le comportement de votre application, quel que soit son bucket. Votre application peut savoir dans quel bucket elle se trouve actuellement en appelant la nouvelle méthode UsageStatsManager.getAppStandbyBucket().
Bonnes pratiques
Si votre application suit déjà les bonnes pratiques pour les fonctionnalités Sommeil et Mise en veille des applications, vous devriez pouvoir gérer les nouvelles fonctionnalités de gestion de l'alimentation sans difficulté. 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 un bucket ou un autre. Les méthodes de binning du système peuvent changer, et chaque fabricant d'appareils peut choisir d'écrire sa propre application 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 application n'a pas d'activité de lanceur d'applications, il est possible qu'elle ne soit jamais promue au bucket "active". Vous voudrez peut-être repenser votre application pour intégrer une telle activité.
- Si les notifications de l'application ne sont pas exploitables, les utilisateurs ne pourront pas déclencher la promotion de l'application dans le bucket actif en interagissant avec les notifications. Dans ce cas, vous pouvez repenser certaines 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 FCM à priorité élevée, l'utilisateur ne pourra pas interagir avec l'application et la promouvoir dans le bucket "active". En fait, la seule utilisation prévue pour les messages FCM à priorité élevée consiste à envoyer une notification à l'utilisateur. Cette situation ne doit donc jamais se produire. Si vous marquez de manière inappropriée un message FCM comme étant prioritaire alors qu'il ne déclenche pas d'interaction utilisateur, cela peut avoir d'autres conséquences négatives. Par exemple, l'application peut épuiser son quota et ainsi traiter des messages FCM véritablement urgents comme une priorité normale.
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 avec des notifications uniquement pour essayer de garder votre application dans le bucket "active".
Si les applications sont réparties sur plusieurs packages, ces packages peuvent se trouver dans des buckets différents et, par conséquent, avoir des niveaux d'accès différents. Veillez à tester ces applications avec les packages attribués à différents buckets pour vous assurer qu'elles se comportent correctement.
Améliorations apportées à l'économiseur de batterie
Android 9 apporte un certain nombre d'améliorations au mode Économiseur de batterie. C'est le fabricant de l'appareil qui détermine précisément les restrictions qui s'appliquent. Par exemple, sur les builds AOSP, le système applique les restrictions suivantes:
- Le système met les applications en mode de mise en veille de manière plus agressive, au lieu d'attendre qu'elles soient inactives.
- Les limites d'exécution en arrière-plan s'appliquent à toutes les applications, quel que soit leur niveau d'API cible.
- Les services de localisation peuvent être désactivés lorsque l'écran est éteint.
- Les applications en arrière-plan n'ont pas accès au réseau.
De plus, il existe d'autres optimisations de consommation d'énergie propres à chaque appareil. Pour en savoir plus, consultez la page qui décrit les restrictions de gestion de l'alimentation.
Comme toujours, nous vous recommandons de tester votre application lorsque l'économiseur de batterie est actif. Vous pouvez l'activer manuellement sur l'écran Settings > Battery Saver (Paramètres > Économiseur de batterie) de l'appareil.
Test et dépannage
Les nouvelles fonctionnalités de gestion de l'alimentation affectent toutes les applications exécutées sur les appareils Android 9, qu'elles ciblent ou non Android 9. Il est important de vous assurer que votre application se comporte correctement sur ces appareils.
Veillez à tester les principaux cas d'utilisation de votre application dans différentes conditions, afin de voir comment les fonctionnalités de gestion de l'alimentation interagissent les unes avec les autres. Vous pouvez utiliser les commandes Android Debug Bridge pour activer et désactiver certaines fonctionnalités.
Commandes Android Debug Bridge
Vous pouvez utiliser les commandes shell Android Debug Bridge pour tester plusieurs des fonctionnalités de gestion de l'alimentation.
Pour en savoir plus sur l'utilisation d'ADB pour mettre votre appareil en veille, consultez Tester avec les fonctionnalités Sommeil et Mise en veille des applications.
Buckets App Standby
Vous pouvez utiliser ADB pour attribuer manuellement votre application à un bucket App Standby. Pour modifier le bucket d'une application, exécutez la commande suivante:
$ adb shell am set-standby-bucket packagename active|working_set|frequent|rare
Vous pouvez également utiliser cette commande pour définir plusieurs packages à la fois :
$ adb shell am set-standby-bucket package1 bucket1 package2 bucket2...
Pour vérifier le bucket dans lequel se trouve une application, exécutez la commande suivante :
$ adb shell am get-standby-bucket [packagename]
Si vous ne transmettez pas de paramètre packagename, la commande liste les buckets pour toutes les applications. Une application peut également trouver son bucket au moment de l'exécution en appelant la nouvelle méthode UsageStatsManager.getAppStandbyBucket().
Économiseur de batterie
Plusieurs commandes permettent de tester le comportement de votre application en faible consommation d'énergie.
Pour simuler le débranchement de l'appareil, utilisez la commande
$ adb shell dumpsys battery unplug
Pour tester le comportement de l'appareil en faible consommation d'énergie, utilisez la commande suivante :
$ adb shell settings put global low_power 1
Une fois les tests terminés, vous pouvez annuler les paramètres manuels de l'appareil à l'aide de la commande suivante:
$ adb shell dumpsys battery reset