Santé Android

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

  • Séparation plus nette entre le framework et le code du fournisseur.
  • Déprécie le démon healthd inutile.
  • De plus grands degrés de liberté 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 mineure de health@2.0 HAL. Ce nouveau 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 framework pour indiquer l'état de la batterie de l'appareil

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

  • Supprimer les API inutilisées liées au chargeur
  • Supprimer StorageAttribute inutilisé et les champs associés
  • Prise en charge du chargement du quai.

Exigences

Appareils fonctionnant sous Android 9 et Android 10

Les appareils lancés avec Android 9 doivent fournir le HAL 2.x (et ne doivent pas fournir le HAL 1.0) ou le HAL AIDL. Les appareils qui ne sont pas lancés avec Android 9 mais qui envisagent 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 le HAL 2.0 et la transition depuis l'ancien HAL 1.0.

Appareils fonctionnant sous Android 11 et Android 12

Les appareils lancés avec Android 11 doivent fournir le HAL 2.1 (et ne doivent pas fournir le HAL 1.0 ou 2.0) ou le HAL AIDL. Les appareils qui ne sont pas lancés avec Android 11 mais qui envisagent de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix version 5 (publiée 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 sont pas lancés avec Android 11 et qui ne prévoient pas de mettre à jour l'image du fournisseur de fournir le HAL 2.1.

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

Appareils fonctionnant sous Android 13 et supérieur

Les appareils lancés avec Android 13 doivent fournir le HAL AIDL (et ne doivent pas fournir le HAL HIDL). Les appareils qui ne sont pas lancés avec Android 13 mais qui envisagent de mettre à jour l’image du fournisseur vers Target Framework Compatibility Matrix version 7 (publiée 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 le HAL AIDL.

Les appareils ne doivent pas fournir le HAL HIDL 1.0.

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

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 sur Android 13.
  • charger : exécutable fonctionnant en mode de chargement hors tension et affichant l'animation de chargement du téléphone.
  • recovery : exécutable exécuté en mode recovery qui doit récupérer les informations sur 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 exécuté sous Android qui récupère les informations de stockage et les fournit au framework.

Santé dans Android 8.x

Sous Android 8.x, le composant d'intégrité 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 est lié statiquement à libhealthd_android , libbatterymonitor et libbatteryservice .
  • health@1.0-impl est lié statiquement à libhealthd. BOARD .

Chaque carte peut personnaliser une libhealthd. BOARD ; il est déterminé au moment de la construction à quel lien le chargeur, health@1.0-impl et la récupération sont liés.

Pour les autres modes :

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

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

  • le chargeur est lié statiquement à libhealthd. BOARD , libhealthd_charger et libbatterymonitor .
  • la récupération est liée statiquement à libhealthd. BOARD et libbatterymonitor .

Santé dans Android 9

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

Figure 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 du code existant est conservé afin que l'image système Android 9 soit compatible avec l'image du fournisseur Android 8.x. Le framework 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 sous Android 9

Figure 4. Santé sous Android 9, mode de chargement 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 de Health 2.1 n'existe pas, le système revient au chemin de code existant, 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)      ] |
+-------------------------------------+

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

Infrastructures Santé HAL 2.1

Figure 5. Infrastructure Santé HAL 2.1

Santé dans Android 13

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

Infrastructures Santé AIDL HAL

Figure 6. Infrastructure Santé AIDL HAL

Interface HIDL-HAL 2.0

Le HAL health@2.0 fournit les mêmes fonctionnalités 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 liaison (c'est-à-dire IBatteryPropertiesRegistrar ).

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

  • registerCallback , pour remplacer IBatteryPropertiesRegistrar.registerListener
  • unregisterCallback , pour remplacer IBatteryPropertiesRegistrar.unregisterListener
  • update , pour remplacer IBatteryPropertiesRegistrar.scheduleUpdate
  • IBatteryPropertiesRegistrar.getProperties sont remplacés par les éléments suivants :
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

De plus, 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 batterie, courant, tension, charge, technologie, etc.)
  • Informations de stockage (informations sur le périphérique de stockage, statistiques de disque)

Pour plus d'informations sur la mise en œuvre du service Health 2.0, voir Implémentation de Health 2.0 .

Interface HIDL-HAL 2.1

Le health@2.1 HAL prend en charge la charge hors mode 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 ce 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 requise 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 l'état de 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’état de l’appareil disponibles via health@2.0 HAL, notamment :

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

Consultez le diagramme UML suivant pour connaître les classes utiles à l’implémentation de Health HAL :

Santé 2.1 Diagramme HAL UML

Figure 7. Diagramme UML de santé HAL 2.1

Pour plus d’informations sur la mise en œuvre du service Health 2.1, voir Implémentation de Health 2.1 .

Interface AIDL HAL version 1

Modifications de l'API

Le HAL AIDL version 1 prend en charge des API similaires au 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 aux chargeurs introduites dans HIDL HAL 2.1 ne sont pas portées vers AIDL HAL. Étant donné que la fonctionnalité de facturation hors mode réside uniquement sur la partition /vendor , les API sur l'interface du fournisseur ne sont pas nécessaires. Pour mettre en œuvre correctement la charge hors mode, voir le chargeur ci-dessous.
  • Type StorageAttribute et les champs associés sont supprimés car ils sont inutilisés.
  • chargerDockOnline est ajouté à HealthInfo pour prendre en charge le chargement sur station d'accueil.

Mise en œuvre

Consultez le diagramme UML suivant pour connaître les classes utiles à l’implémentation de Health HAL :

Diagramme Santé AIDL HAL UML

Figure 8. Diagramme UML de Health AIDL HAL

Pour plus d’informations sur la mise en œuvre du service Health AIDL, consultez Implémentation de Health AIDL HAL .

Récupération

Android 13 prend en charge le classeur lors de 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 ce qui suit :

Chargeur

La fonctionnalité de chargement hors mode est déplacée de /system vers /vendor . Pour les appareils lancés avec Android 13, s’ils prennent en charge la charge hors mode, le binaire du service HAL doit prendre en charge le mode chargeur. Pour ce faire, reportez-vous à l'implémentation 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 votre appareil possède l'une des propriétés système ro.charger.* définies, reportez-vous aux propriétés système du chargeur .