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

Android 13 inclut android.hardware.health AIDL HAL, une conversion de health@2.1 HAL. Cette nouvelle HAL présente les avantages suivants :

  • Supprimer les API liées au chargeur inutilisées
  • Supprimer StorageAttribute inutilisé et les champs associés
  • Prend en charge la charge de la station d'accueil.

Conditions

Appareils exécutant Android 9 et Android 10

Les appareils lancés avec Android 9 doivent fournir la HAL 2.x (et ne doivent pas fournir la HAL 1.0) ou la HAL AIDL. 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ée dans Android 9) doivent supprimer les implémentations HAL 1.0 existantes et fournir la HAL 2.x ou la HAL AIDL.

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

Appareils exécutant Android 11 et Android 12

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) ou la HAL AIDL. 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 ou la HAL AIDL. 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.

Appareils exécutant Android 13 et versions ultérieures

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

Les appareils ne doivent pas fournir le HIDL 1.0 HAL.

AOSP comprend plusieurs bibliothèques d'assistance conçues pour vous aider à implémenter AIDL HAL et la transition depuis les anciens HIDL HAL.

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.
  • santé AIDL HAL : abréviation de android.hardware.health .
    • La version 1 est publiée dans Android 13.
  • 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)      ] |
+-------------------------------------+

Voir le schéma simplifié suivant pour les différents modes :

Infrastructure HAL 2.1 Santé

Figure 5. Infrastructure HAL 2.1 Santé

Santé dans Android 13

Dans Android 13, la santé AIDL HAL est introduite. Le composant de santé fonctionne comme détaillé dans le schéma suivant :

Santé AIDL Infrastructure HAL

Figure 6. Infrastructure HAL Santé AIDL

Interface HIDL 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)

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

Interface HIDL 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)

Voir le diagramme UML suivant pour les classes utiles à l'implémentation HAL de santé :

Santé 2.1 Diagramme HAL UML

Figure 7. Diagramme UML HAL 2.1 Santé

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

Interface AIDL HAL version 1

Modifications de l'API

La HAL AIDL version 1 prend en charge des API similaires à la HAL HIDL 2.1. Par rapport à l'interface HIDL 2.1, les éléments suivants sont modifiés dans l'API :

  • Les API liées au chargeur introduites dans HIDL HAL 2.1 ne sont pas portées sur AIDL HAL. Étant donné que la fonctionnalité de charge en mode hors tension n'existe que sur la partition /vendor , les API de l'interface fournisseur ne sont pas nécessaires. Pour mettre en œuvre correctement la charge hors mode, voir le chargeur ci-dessous.
  • Le type StorageAttribute et les champs associés sont supprimés car ils ne sont pas utilisés.
  • chargerDockOnline est ajouté à HealthInfo pour prendre en charge la charge de la station d'accueil.

Mise en œuvre

Voir le diagramme UML suivant pour les classes utiles à l'implémentation HAL de santé :

Diagramme UML AIDL HAL Santé

Figure 8. Diagramme UML HAL Health AIDL

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

Récupération

Android 13 prend en charge le classeur dans la récupération. L'installation du service Health AIDL pour la récupération lui permet de s'exécuter en mode de récupération.

Pour plus d'informations sur l'installation du service Health AIDL pour la récupération, consultez les éléments suivants :

Chargeur

La fonctionnalité de charge en mode hors tension est déplacée de /system vers /vendor . Pour les appareils lancés avec Android 13, s'ils prennent en charge la charge en mode hors tension, le binaire du service HAL doit prendre en charge le mode chargeur. Pour ce faire, reportez-vous à la section mise en œuvre du chargeur .

Propriétés du système de chargeur

Les propriétés ro.charger.* ne sont plus lisibles par le binaire charger dans /vendor . Si l'une des propriétés système ro.charger.* est définie sur votre appareil, reportez-vous aux propriétés système du chargeur .