Android 9 (niveau d'API 28) introduit de nouvelles fonctionnalités pour améliorer la gestion de l'alimentation des appareils. 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 divisent en deux catégories:
- Buckets de mise en veille des applications
- Le système limite l'accès des applications l'accès aux ressources de l'appareil, 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 impose des restrictions sur toutes les applications. Il s'agit d'une fonctionnalité existante amélioré 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 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 appli se trouve dans le bucket "working set" si elle s'exécute souvent, mais ce n'est pas le cas actuellement. actif. 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 ne sont jamais exécutées, sont attribuées au bucket "Never". Le système impose des restrictions strictes sur ces applications.
Le système attribue dynamiquement chaque application à un bucket prioritaire, puis réattribue le applications en fonction des 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. Les applications plus actives sont attribuées à des buckets donner une priorité plus élevée aux applications, ce qui de ressources système supplémentaires disponibles pour l'application. En particulier, le bucket détermine la fréquence d'exécution des jobs de l'appli, la fréquence de déclenchement les alarmes et la fréquence à laquelle l'application peut recevoir des messages Firebase Cloud à priorité élevée Messages (FCM). 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 identifier 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 Sommeil et mise en veille des applications la gestion des nouvelles fonctionnalités de gestion de l'alimentation ne devrait pas être difficile. Toutefois, certains comportements d'application qui fonctionnaient correctement auparavant peuvent désormais causer 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. Vous voudrez peut-être remanier votre application pour avoir un tel 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 dans ce cas, vous pouvez remanier certaines notifications appropriées afin qu'elles permettent une réponse de l'utilisateur. 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 marquer de manière inappropriée un message FCM comme prioritaire lorsqu'il ne se déclenche pas interaction avec l'utilisateur, cela peut avoir d'autres conséquences négatives ; par exemple, il peut entraîner l'épuisement de son quota, entraînant une urgence Messages FCM à traiter avec la priorité normale.
Remarque:Si l'utilisateur ignore une notification à plusieurs reprises, permet à l'utilisateur de bloquer cette notification à 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 de votre application.
Améliorations apportées à l'économiseur de batterie
Android 9 apporte un certain nombre d'améliorations au mode Économiseur de batterie. Le fabricant de l'appareil détermine les restrictions précises qui lui sont 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, quelle que soit leur API cible d'application.
- Les services de localisation peuvent être désactivés lorsque l'écran est éteint.
- Les applications d'arrière-plan n'ont pas accès au réseau.
Il existe également d'autres optimisations d'alimentation spécifiques à chaque appareil. Pleine consultez la page décrivant la gestion de l'alimentation restrictions.
Comme toujours, nous vous recommandons 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 les appareils Android 9, que vous ou non celles qui ciblent Android 9. Il est important de s'assurer que le comportement de votre application correctement sur ces appareils.
Veillez à tester les principaux cas d'utilisation de votre application dans différentes conditions, pour voir comment les fonctionnalités de gestion de l'alimentation interagissent entre elles. Vous pouvez utiliser Android Debug Bridge pour activer ou désactiver certaines et désactiver les 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