HAL des statistiques d'alimentation

L'alimentation du sous-système de l'appareil est souvent mesurée et enregistrée dans un environnement de laboratoire pour différentes conditions d'état stable, par exemple lorsque l'écran est allumé ou que l'appareil est en mode veille. Cela fonctionne pour les sous-systèmes avec une consommation d'énergie constante ou dans des conditions facilement mesurables en laboratoire, mais pas pour certains cas d'utilisation, par exemple lorsqu'un écran affiche une vidéo.

IPower.hal 1.0 fournit une interface permettant de transmettre des conseils d'alimentation et de générer des données cumulées sur les métriques d'état de veille du sous-système. Sous Android 10 et versions ultérieures, la fonction de création de rapports statistiques cumulés se trouve dans les API de collecte des statistiques d'alimentation IPowerStats.hal et permet de récupérer des données sur la consommation d'énergie sur l'appareil. Cette modification remplace la partie de collecte des statistiques cumulatives de l'interface IPower.hal pour une séparation plus claire des fonctionnalités.

Les lectures du service IPowerStats ne sont pas périodiques. Elles se produisent à des moments clés, par exemple lorsqu'il y a une baisse de 1% de la batterie. Les lectures sont moins fréquentes lorsque la décharge de la batterie est faible et plus fréquentes lorsqu'elle est élevée. Les données peuvent être renvoyées aux serveurs et utilisées dans les rapports de bugs pour l'analyse et le tri. Cela s'inscrit dans nos efforts continus visant à réduire la consommation d'énergie et à augmenter l'autonomie de la batterie.

IPower.hal et IPowerStats.hal

Les interfaces IPower.hal et IPowerStats.hal sont disponibles sur Android 10, mais la fonctionnalité de collecte des statistiques IPower.hal n'est disponible que depuis l'interface IPowerStats.hal. La fonctionnalité IPowerStats.hal inclut des API permettant d'acquérir et d'utiliser les données collectées à partir de mesures d'alimentation sur l'appareil pour les appareils compatibles:

  • Effectue des mesures d'énergie au niveau du rail pour les clients à basse fréquence (getRailInfo) et à haute fréquence (streamEnergyData), et indique l'énergie accumulée depuis le démarrage.
  • Fournit des informations sur chaque PowerEntity compatible pour laquelle des données sont disponibles. Un PowerEntity est un sous-système de plate-forme, un périphérique ou un domaine d'alimentation qui a un impact sur la consommation d'énergie totale de l'appareil.
  • Indique l'ensemble des états des entités d'alimentation (getPowerEntityStateInfo) pour lesquels les entités spécifiées fournissent des données de résidence, puis indique les données cumulées pour chaque PowerEntity spécifié.

Les API IPowerStats.hal sont utilisées par les clients suivants:

  • Statsd, pour collecter les métriques de consommation d'énergie par rail.
  • Perfetto, pour corréler la consommation d'énergie à l'activité du processeur.
  • Batterystats, pour améliorer l'attribution de la batterie en utilisant des données mesurées plutôt que d'estimer la consommation de la batterie à partir de constantes prédéfinies dans power_profile.xml.

Avec Android 10 ou version ultérieure, un fabricant d'appareils peut choisir entre les fonctions IPower.hal et IPowerStats.hal, mais tous les clients doivent utiliser IPower.hal si IPowerStats.hal n'est pas implémenté .

Options d'implémentation d'IPowerStats.hal

Seules les fonctions IPower.hal sont disponibles sur Android 7 à Android 9. Les appareils qui ont été mis à niveau vers Android 10 doivent disposer d'un sous-système matériel de surveillance de l'alimentation ou d'autres moyens permettant de surveiller et d'enregistrer les statistiques d'alimentation. Certains SoC collectent des statistiques sur la consommation d'énergie pour vous, ou vous pouvez obtenir des informations sur la résidence de l'état de l'entité d'alimentation via un logiciel. Le matériel de surveillance de l'alimentation n'est nécessaire que pour prendre en charge getRailInfo(), getEnergyData() et streamEnergyData().

Si vous implémentez IPowerStats.hal sans matériel de surveillance de l'alimentation, getRailInfo(), getEnergyData() et streamEnergyData() renvoient NOT_SUPPORTED. De même, getPowerEntityInfo(), getPowerEntityStateInfo() et getPowerEntityStateResidencyData() peuvent également renvoyer NOT_SUPPORTED s'il n'est pas destiné à être utilisé.

Voici quelques exemples de données renvoyées par les API de surveillance des voies ferrées :

  • La barre d'alimentation de l'écran a consommé X µW.
  • La barre d'alimentation du modem a consommé Y µW.

Voici des exemples de données renvoyées par les API d'état de veille du sous-système :

  • Le modem était en veille pendant X ms.
  • Le SoC était dans l'état de réduction de la puissance pendant Y ms.
  • Le GPU était dans l'état de suspension pendant Z ms.

Utiliser un sous-système de surveillance de l'alimentation matériel

Si la conception de votre appareil comporte un sous-système de surveillance de l'alimentation matérielle, implémentez IPowerStats.hal en créant un seul nœud sysfs à partir duquel PowerStats.hal peut analyser les données, ou en créant une collection d'appels système de type ioctl.

Vous devez implémenter votre pilote de kernel de manière à éviter tout débordement de l'accumulateur. L'algorithme utilisé dépend de la conception unique de votre sous-système de surveillance de l'alimentation matérielle, qui doit fournir à la fois des mesures instantanées et moyennes de la tension et du courant du bus. Le pilote du kernel doit capturer ces données de manière à ne pas effacer les accumulateurs d'énergie. Il doit également conserver les données d'énergie cumulées pour chaque sous-rail depuis le démarrage, sous la forme d'une variable 64 bits qui est incrémentée avec la lecture d'énergie de chaque requête d'accumulateur.

Les statistiques d'un composant donné (ou éventuellement de plusieurs composants) doivent se trouver dans un seul nœud. Bien que ce ne soit pas une utilisation conventionnelle de sysfs (qui limite normalement chaque nœud à une seule valeur), cela garantit que toutes les données sont cohérentes.

Conseils de conception

  • Maintenez la latence faible (1 ms maximum) lors de la lecture à partir du nœud sysfs ou lors de l'exécution d'appels système.
  • Assurez-vous que la fonctionnalité de statistiques associée n'augmente pas de manière mesurable la décharge d'énergie:
    • N'augmentez pas les réveils du point d'accès (PA) et/ou du sous-système pour suivre des paramètres tels que le temps passé en mode veille.
    • Transférez les statistiques entre le processeur d'application et le micrologiciel de manière opportuniste avec d'autres trafics lorsque cela est possible.
  • Si nécessaire, le sous-système peut utiliser les fonctions de pilote suivantes:
    • Mise en cache interne des données pour éviter les latences/réveils au détriment des données légèrement obsolètes.
    • Effectuer une extrapolation lorsque le sous-système est en veille, afin de fournir un temps de veille mis à jour sans réveiller le sous-système.

Choisir des composants, des sous-systèmes et des statistiques

Lorsque vous choisissez les composants ou sous-systèmes à partir desquels collecter les données IPowerStats.hal, sélectionnez tout élément de l'appareil qui consomme un courant important (5 mA ou plus) ou qui prend en charge plusieurs modes de consommation d'énergie, comme les éléments suivants:

  • Sous-systèmes SoC individuels
  • Sous-systèmes situés partiellement ou complètement en dehors du SoC, tels que le Wi-Fi, le processeur d'image ou le processeur de sécurité.
  • Périphériques tels que les LED et les caméras à haute puissance
  • Domaines d'alimentation qui utilisent différents modes (par exemple, le domaine d'alimentation du SoC dans son ensemble).

Personnalisation

Cette fonctionnalité facultative peut être personnalisée. Concevez des cas d'utilisation et personnalisez votre utilisation:

  • Déterminez les rails à mesurer et la fréquence à laquelle vous devez les mesurer.
  • Décidez quand lire les données et comment les interpréter.
  • Déterminez les mesures à prendre et le moment où les prendre en fonction de vos données.

Validation

Les tests VTS garantissent que les exigences Android sont respectées. Les commentaires dans IPowerStats.hal permettent de vérifier qu'un appareil est conforme.

Par exemple, si vous appelez getRailInfo() et qu'il ne renvoie rien, le test VTS échoue, car vous n'avez pas reçu d'informations sur les rails surveillés ou l'état SUCCESS a été renvoyé. De même, si vous avez reçu des informations sur les chemins de fer, mais qu'elles étaient accompagnées d'une réponse NON_SUPPORTED ou FILE_SYSTEM_ERROR, cela constitue également un échec. Le VTS vérifie que les spécifications du fabricant de l'appareil sont respectées dans le fichier HAL, à l'aide des exigences des commentaires IPower.hal et IPowerStats.hal. Vous trouverez ci-dessous un exemple de commentaires utilisés lors des tests VTS:

/**
* Rail information:
* Reports information related to the rails being monitored.
*
* @return rails Information about monitored rails.
* @return status SUCCESS on success or NOT_SUPPORTED if
* feature is not enabled or FILESYSTEM_ERROR on filesystem nodes
* access error.
*/
getRailInfo()
generates(vec<e;RailInfo>e; rails, Status status);