Android 9 (niveau d'API 28) introduit de nouvelles fonctionnalités pour améliorer la gestion de l'alimentation de l'appareil. Ces ainsi que des fonctionnalités déjà présentes dans les versions précédentes, pour s'assurer que les ressources système sont attribuées aux applications qui en ont le plus besoin.
Les fonctionnalités de gestion de l'alimentation se répartissent 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, comme le processeur ou la batterie, en fonction des habitudes d'utilisation de l'utilisateur. Il s'agit d'une nouvelle fonctionnalité Android 9.
- Améliorations apportées à l'Économiseur de batterie
- Lorsque l'économiseur de batterie est activé, le système applique des restrictions à 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 de mise en veille des applications. Les buckets de mise en veille des applications permettent au système de donner la priorité aux applications de ressources en fonction sur la récence et la fréquence de leur utilisation. En fonction de l'utilisation de l'appli d'entraînement, 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.
Les cinq catégories classent les applications par ordre de priorité en fonction des caractéristiques suivantes:
- Actif
Une application se trouve dans le bucket "active" si l'utilisateur l'utilise actuellement, par exemple 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 n'impose aucune restriction concernant les tâches, les alarmes ou les messages FCM de l'application.
- 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 que l'utilisateur lance presque tous les jours est probablement dans l’ensemble de travail. Les applications sont également promues à l'ensemble de travail bucket s'ils sont utilisés 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 d'exécuter des jobs et de déclencher des alarmes, et impose un plafond messages FCM à priorité élevée. 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 ne court que lorsqu'il séjourne dans cet hôtel peut être bucket.
Si une appli se trouve dans le bucket "rare", le système impose des restrictions strictes sur sa capacité à exécuter des jobs, à 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 consultez Restrictions de gestion de l'alimentation.
- Jamais
Les applications qui ont été installées, mais qui n'ont jamais été exécutées, sont attribuées au bucket "never" (jamais). Le système impose des restrictions strictes sur ces applications.
Le système attribue dynamiquement chaque application à un bucket prioritaire, puis réattribue le des applications selon les besoins. Le système peut s'appuyer sur une application préchargée pour déterminer la probabilité que chaque doit être utilisée et les attribue aux buckets appropriés. Si le système application n'est pas présente sur un appareil, le système trie par défaut les applications en fonction 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, 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 s'appliquent uniquement lorsque l'appareil est sur batterie. le système n'impose pas ces restrictions aux applications lorsque l'appareil est en charge.
Chaque fabricant peut définir ses propres critères de désactivation des applications
est attribué aux buckets. Vous ne devez pas essayer d'influencer le bucket dans lequel se trouve votre application
auquel vous êtes affecté. Concentrez-vous plutôt sur le comportement de votre application, quel que soit
le bucket dans lequel elle pourrait se trouver. Votre application peut connaître le bucket dans lequel elle se trouve 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, 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 un seul bucket ou une autre. Les méthodes de binning du système peuvent changer, et chaque appareil peut choisir d'écrire sa propre application de binning avec sa 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 actif. Il faudra peut-être repenser votre application pour qu'elle intègre cette activité.
- Si les notifications de l'application ne sont pas exploitables, les utilisateurs ne pourront pas les 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 Conception des notifications Material Design des modèles.
De même, si l'application n'affiche pas de notification à la réception d'une message FCM à priorité élevée, il ne donne pas à l'utilisateur l'occasion d'interagir avec l'application et ne la fait donc pas connaître 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 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, votre application peut épuiser son quota, ce qui entraîne le traitement des messages FCM réellement urgents comme des messages de 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 juste pour essayer de maintenir votre application dans actif !
Si les applications sont réparties sur plusieurs packages, ceux-ci peuvent se trouver dans et ont donc 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.
Améliorations apportées à l'économiseur de batterie
Android 9 apporte plusieurs améliorations au mode Économiseur de batterie. Le fabricant de l'appareil détermine les restrictions précises imposées. Par exemple, sur les compilations AOSP, le système applique les restrictions suivantes:
- Le système place les applications en mode veille de manière plus agressive, au lieu de en attente de l'inactivité de l'application.
- 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.
Il existe également d'autres optimisations d'alimentation spécifiques à chaque appareil. Pour en savoir plus, consultez la page décrivant les restrictions de gestion de l'alimentation.
Comme toujours, il est recommandé de tester votre application lorsque l'économiseur de batterie est actif. Toi Vous pouvez l'activer manuellement dans les Paramètres > Piles ou batterie Économiseur de données.
Test et dépannage
Les nouvelles fonctionnalités de gestion de l'alimentation affectent toutes les applications exécutées sur des appareils Android 9, qu'elles ciblent ou non Android 9. Il importe 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, utilisez 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 cette commande:
$ adb shell dumpsys battery reset