Santé Android

Android 9 inclut android.hardware.health HAL 2.0, une mise à niveau majeure de la version de health@1.0 HAL. Cette nouvelle HAL présente les avantages suivants :

  • Séparation plus nette entre le framework et le code du fournisseur.
  • healthd le démon sain inutile.
  • Degrés de liberté accrus pour la personnalisation des fournisseurs dans les rapports d'informations sur la santé.
  • Plus d'informations sur l'état de l'appareil que la simple batterie.

Android 11 inclut android.hardware.health HAL 2.1, une mise à niveau de version mineure de health@2.0 HAL. Cette nouvelle HAL présente les avantages suivants :

  • Plus facile à mettre en œuvre
  • Meilleure conformité avec les API HAL 2.0 existantes
  • Meilleure séparation des aigus dans le code de charge hors mode
  • Meilleure prise en charge du cadre pour indiquer la santé de la batterie de l'appareil

Exigences

Les appareils lancés avec Android 9 doivent fournir la HAL 2.0 (et ne doivent pas fournir la HAL 1.0). Les appareils qui ne se lancent pas avec Android 9 mais qui prévoient de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix Version 3 (publié dans Android 9) doivent supprimer les implémentations HAL 1.0 existantes et fournir la HAL 2.0.

Les appareils lancés avec Android 11 doivent fournir la HAL 2.1 (et ne doivent pas fournir la HAL 1.0 ou 2.0). Les appareils qui ne se lancent pas avec Android 11 mais qui prévoient de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix Version 5 (publié dans Android 11) doivent supprimer les implémentations HAL 2.0 existantes et fournir la HAL 2.1. Il est également recommandé aux appareils qui ne se lancent pas avec Android 11 et qui ne prévoient pas de mettre à jour l'image du fournisseur de fournir la HAL 2.1.

AOSP comprend plusieurs bibliothèques d'assistance conçues pour vous aider à implémenter la HAL 2.1 et la transition depuis l'ancienne HAL 1.0.

Terminologie

  • health@1.0 : abréviation de android.hardware.health@1.0 . Fait référence à la santé HIDL HAL version 1.0 publiée dans Android 8.0.
  • health@2.0 : abréviation de android.hardware.health@2.0 . Fait référence à la santé HIDL HAL version 2.0 publiée dans Android 9.
  • health@2.1 : abréviation de android.hardware.health@2.1 . Fait référence à la santé HIDL HAL version 2.1 publiée dans Android 11.
  • chargeur : exécutable fonctionnant en charge hors mode qui affiche l'animation de charge du téléphone.
  • recovery : exécutable tournant en mode recovery qui doit récupérer les informations de la batterie.
  • healthd : démon hérité fonctionnant sous Android qui récupère les informations relatives à la santé et les fournit au framework.
  • storaged : démon fonctionnant sous Android qui récupère les informations de stockage et les fournit au framework.

Santé dans Android 8.x

Dans Android 8.x, le composant de santé fonctionne comme détaillé dans le schéma suivant :

Santé dans Android 8.x

Figure 1 . Santé dans Android 8.x

Dans ce schéma :

  • Un (1) appel binder et un (1) appel hwbinder sont utilisés par le framework pour communiquer avec le matériel.
  • healthd statiquement à libhealthd_android , libbatterymonitor et libbatteryservice .
  • health@1.0-impl établit un lien statique vers libhealthd. BOARD .

Chaque carte peut personnaliser un libhealthd. BOARD ; il est déterminé au moment de la construction à quel chargeur, health@1.0-impl et recovery sont liés.

Pour les autres modes :

Mode de chargement et de récupération hors mode dans Android 8.x

Figure 2. Santé sous Android 8.x, mode de charge et de récupération hors mode

  • chargeur établit un lien statique avec libhealthd. BOARD , libhealthd_charger et libbatterymonitor .
  • recovery est lié de manière statique à libhealthd. BOARD et libbatterymonitor .

Santé dans Android 9

Dans Android 9, le composant de santé fonctionne comme détaillé dans le schéma suivant : Santé dans Android 9

Illustration 3 . Santé dans Android 9

Le framework tente de récupérer le service health@2.0 à partir de hwservicemanager . En cas d'échec, il appelle health@1.0 (sous Android 8.x). Le chemin de code hérité est conservé afin que l'image système Android 9 soit compatible avec l'image du fournisseur Android 8.x. La structure ne récupère pas les informations des deux HAL, car une seule version de service (1.0 ou 2.0) peut exister sur l'appareil.

Pour les autres modes :

Chargement et récupération hors mode dans Android 9

Figure 4. Santé sous Android 9, mode de charge et de récupération hors mode

Santé dans Android 11

Dans Android 11, le composant de santé fonctionne comme détaillé dans le schéma suivant :

[system]
    | getService()
    V
[health@2.1-service]
        | getService(stub=true)
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

Si l'implémentation d'intégrité 2.1 n'existe pas, le système revient au chemin de code hérité, comme décrit dans les sections précédentes.

Pour les autres modes :

[       charger          ]
    | getService()      |  (legacy code path)
    V                   +-------------------------------------------------+
[health@2.1-service]                                                      |
        | getService(stub=true)                                           |
        V                                                                 |
[      health@2.0-impl-2.1-<device>.so      ]                             |
        |                                  | (device-dependent linkage)   |
        V                                  V                              |
+---------Helper libs for impl--------+   [libhealthd.device]             |
| [libhealthloop (uevent, wakealarm)] |                                   |
| [libhealth2impl (IHealth impl)    ] | <---------------------------------+
| [libbatterymonitor (battery)      ] |
+-------------------------------------+
[recovery]
        | getService() w/o hwservicemanager
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

Interface HAL 2.0

L'HAL health@2.0 fournit la même fonctionnalité au framework que l'ancien démon healthd. Il fournit également des API similaires à celles fournies précédemment par healthd en tant que service de classeur (c'est-à-dire IBatteryPropertiesRegistrar ).

L'interface principale, IHealth , fournit les fonctions suivantes :

  • registerCallback , pour remplacer IBatteryPropertiesRegistrar.registerListener
  • unregisterCallback , pour remplacer IBatteryPropertiesRegistrar.unregisterListener
  • update , pour remplacer IBatteryPropertiesRegistrar.scheduleUpdate
  • IBatteryPropertiesRegistrar.getProperties sont remplacés par ce qui suit :
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

En outre, IHealth fournit les nouvelles API suivantes pour storaged afin de récupérer des informations relatives au stockage spécifiques au fournisseur :

  • getStorageInfo
  • getDiskStats

Une nouvelle structure, @2.0::HealthInfo , est renvoyée via des rappels et getHealthInfo . Cette structure contient toutes les informations sur l'état de l'appareil disponibles via health@2.0 HAL, notamment :

  • Informations de charge (AC/USB/sans fil, courant, tension, etc.)
  • Informations sur la batterie (présence, niveau de la batterie, courant, tension, charge, technologie, etc.)
  • Informations de stockage (informations sur le périphérique de stockage, statistiques sur le disque)

Interface HAL 2.1

La santé@2.1 HAL prend en charge la charge en mode hors tension et fournit plus d'informations sur la batterie.

L'interface principale, IHealth , fournit les fonctions supplémentaires suivantes

  • getHealthConfig : pour récupérer la configuration de cette HAL
  • getHealthInfo_2_1 : une mise à niveau de version mineure vers getHealthInfo
  • shouldKeepScreenOn : pour déterminer si l'écran doit rester allumé en mode chargeur

De plus, l'implémentation de @2.1::IHealth est nécessaire pour prendre en charge @2.1::IHealthInfoCallback pour ses fonctions héritées registerCallback et unregisterCallback . La nouvelle interface de rappel renvoie des informations sur la santé au client à l'aide de sa fonction healthInfoChanged_2_1 au lieu de la fonction héritée healthInfoChanged .

Une nouvelle structure, @2.1::HealthInfo , est renvoyée via des rappels et getHealthInfo_2_1 . Cette structure contient des informations supplémentaires sur l'intégrité de l'appareil disponibles via health@2.0 HAL, notamment :

  • Niveau de capacité de la batterie
  • Temps de charge complet de la batterie maintenant (en secondes)
  • Capacité nominale de charge complète de la batterie (en μAh)

Pour plus d'informations sur l'implémentation du service Health, voir Implémentation de Health .