État du système Android

Android 9 inclut android.hardware.health HAL 2.0, une mise à niveau majeure par rapport à la version HAL health@1.0. 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.
  • Plus de liberté pour la personnalisation des fournisseurs dans les rapports sur les informations de santé.
  • Plus d'informations sur l'état de l'appareil que la batterie.

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

  • Plus facile à implémenter
  • Conformité améliorée avec les API HAL 2.0 existantes
  • Meilleure séparation des aigus dans le code de recharge en mode hors connexion
  • Meilleure prise en charge du framework pour indiquer l'état de la batterie de l'appareil

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

  • Suppression des API inutilisées liées au chargeur
  • Suppression des StorageAttribute et des champs associés inutilisés
  • Prise en charge de la recharge sur station d'accueil.

Conditions requises

Appareils équipés d'Android 9 et d'Android 10

Les appareils lancés avec Android 9 doivent fournir le HAL 2.x (et non le HAL 1.0) ou le HAL AIDL. Les appareils qui ne démarrent pas avec Android 9, mais qui prévoient de mettre à jour l'image du fournisseur vers la version 3 de la matrice de compatibilité du framework cible (publiée dans Android 9) doivent supprimer les implémentations HAL 1.0 existantes et fournir le HAL 2.x ou le HAL AIDL.

AOSP comprend plusieurs bibliothèques d'aide conçues pour vous aider à implémenter le HAL 2.0 et la transition de l'ancienne 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 prévoient de mettre à jour l'image du fournisseur vers la version 5 de la matrice de compatibilité du framework cible (publiée dans Android 11) doivent supprimer les implémentations HAL 2.0 existantes et fournir le HAL 2.1 ou le HAL AIDL. Les appareils qui ne sont pas lancés avec Android 11 et qui ne prévoient pas de mettre à jour l'image du fournisseur sont également recommandés pour fournir la version HAL 2.1.

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

Appareils équipés d'Android 13 ou version ultérieure

Les appareils équipés d'Android 13 doivent fournir le HAL AIDL (et non le HAL HIDL). Les appareils qui ne sont pas lancés avec Android 13, mais qui prévoient de mettre à jour l'image du fournisseur vers la version 7 de la matrice de compatibilité du framework cible (publiée dans Android 13) doivent supprimer les implémentations HAL HIDL existantes et fournir le HAL AIDL. Il est également recommandé de fournir le HAL AIDL pour les appareils qui ne sont pas lancés avec Android 13 et qui ne prévoient pas de mettre à jour l'image du fournisseur.

Les appareils ne doivent pas fournir le HAL HIDL 1.0.

AOSP inclut 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 version 1.0 de la HAL HIDL de santé publiée dans Android 8.0.
  • health@2.0: abréviation de android.hardware.health@2.0. Fait référence à la version 2.0 de la HAL HIDL de santé publiée dans Android 9.
  • health@2.1 : abréviation de android.hardware.health@2.1. Fait référence à la version 2.1 de la HAL HIDL de santé publiée dans Android 11.
  • HAL AIDL de santé : abréviation de android.hardware.health.
    • La version 1 est publiée sous Android 13.
  • charger : exécutable exécuté en mode de charge hors tension qui affiche l'animation de recharge du téléphone.
  • recovery : exécutable exécuté en mode de récupération qui doit récupérer des informations sur la batterie.
  • healthd : ancien daemon exécuté dans Android qui récupère des informations sur l'état et les fournit au framework.
  • storaged : daemon exécuté dans Android qui récupère les informations de stockage et les fournit au framework.

Santé sur Android 8.x

Sous Android 8.x, le composant d'état fonctionne comme indiqué dans le schéma suivant :

Santé sur Android 8.x

Figure 1 : Santé dans Android 8.x

Dans ce diagramme :

  • Le framework utilise un appel de liaison et un appel hwbinder pour communiquer avec le matériel.
  • healthd établit des liens statiques avec libhealthd_android, libbatterymonitor et libbatteryservice.
  • health@1.0-impl est associé de manière statique à libhealthd.BOARD.

Chaque carte peut personnaliser un libhealthd.BOARD différent. Le chargeur, health@1.0-impl et le lien de récupération sont déterminés au moment de la compilation.

Pour les autres modes:

Recharge hors mode et mode récupération sous Android 8.x

Figure 2. Santé sous Android 8.x, recharge hors connexion et mode Recovery.

  • le chargeur est associé de manière statique à libhealthd.BOARD, libhealthd_charger et libbatterymonitor.
  • La récupération établit des liens statiques avec libhealthd.BOARD et libbatterymonitor.

Santé dans Android 9

Sous Android 9, le composant d'état fonctionne comme indiqué dans le schéma suivant : Santé sous 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). L'ancien chemin de code 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 d'informations auprès des deux HAL, car une seule version de service (1.0 ou 2.0) peut exister sur l'appareil.

Pour les autres modes :

Recharge et récupération en mode hors connexion sous Android 9

Figure 4. Santé dans Android 9, recharge hors tension et mode récupération

Santé dans Android 11

Dans Android 11, le composant Santé fonctionne comme indiqué 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 l'état 2.1 n'existe pas, le système revient à l'ancien chemin de code, 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 :

Infrastructure HAL 2.1 Health

Figure 5. Infrastructure Health HAL 2.1

Santé dans Android 13

Dans Android 13, le HAL AIDL de santé est introduit. Le composant d'état fonctionne comme indiqué dans le schéma suivant:

Infrastructure HAL AIDL de santé

Figure 6. Infrastructure HAL de l'AIDL Santé.

Interface HAL HIDL 2.0

Le HAL health@2.0 fournit au framework les mêmes fonctionnalités que l'ancien daemon healthd. Il fournit également des API similaires à celles que healthd fournissait auparavant en tant que service de liaison (IBatteryPropertiesRegistrar, par exemple).

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 les éléments suivants :
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

De plus, IHealth fournit les nouvelles API suivantes pour que storaged puisse récupérer des informations spécifiques au fournisseur concernant le stockage :

  • getStorageInfo
  • getDiskStats

Un nouveau struct, @2.0::HealthInfo, est renvoyé via des rappels et getHealthInfo. Cette structure contient toutes les informations sur l'état de l'appareil disponibles via le HAL health@2.0, y compris les éléments suivants :

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

Pour en savoir plus sur l'implémentation du service Santé 2.0, consultez la section Implémenter Santé 2.0.

Interface HAL HIDL 2.1

La HAL health@2.1 est compatible avec la recharge 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 : mise à niveau vers une version mineure de getHealthInfo
  • shouldKeepScreenOn: permet de déterminer si l'écran doit rester allumé en mode chargeur.

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

Une nouvelle struct, @2.1::HealthInfo, est renvoyée via des rappels et getHealthInfo_2_1. Cette struct contient des informations supplémentaires sur l'état de l'appareil disponibles via le HAL health@2.0, y compris les éléments suivants :

  • Niveau de charge de la batterie
  • Temps de recharge de la batterie pour la remplir complètement (en secondes)
  • Capacité de conception de la batterie à pleine charge (en μAh)

Consultez le schéma UML suivant pour connaître les classes utiles à l'implémentation de HAL pour l'état de santé:

Schéma UML HAL Health 2.1

Figure 7. Schéma UML de Health HAL 2.1.

Pour en savoir plus sur l'implémentation du service Santé 2.1, consultez la section Implémenter Santé 2.1.

Interface HAL AIDL version 1

Modifications apportées à l'API

Le HAL de la version 1 d'AIDL est compatible avec des API similaires à celles du HAL HIDL 2.1. Par rapport à l'interface HIDL 2.1, les modifications suivantes ont été apportées dans l'API:

  • Les API liées au chargeur introduites dans le HAL HIDL 2.1 ne sont pas portées vers le HAL AIDL. Étant donné que la fonctionnalité de facturation hors mode ne réside que sur la partition /vendor, les API de l'interface fournisseur ne sont pas nécessaires. Pour implémenter correctement la recharge hors mode, consultez charger ci-dessous.
  • Le type StorageAttribute et les champs associés sont supprimés, car ils ne sont pas utilisés.
  • chargerDockOnline a été ajouté à HealthInfo pour permettre la recharge sur la station d'accueil.

Implémentation

Consultez le schéma UML suivant pour connaître les classes utiles à l'implémentation de HAL pour l'état de santé:

Diagramme UML HAL Health AIDL

Figure 8. Diagramme UML HAL de Health AIDL.

Pour en savoir plus sur l'implémentation du service AIDL Santé, consultez la section Implémenter le HAL AIDL Santé.

Récupération

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

Pour savoir comment installer le service AIDL de santé en mode récupération, consultez les ressources suivantes :

Chargeur

La fonctionnalité de recharge hors mode est déplacée de /system vers /vendor. Pour les appareils lancés avec Android 13, s'ils sont compatibles avec la recharge hors tension, le binaire du service HAL doit être compatible avec le mode chargeur. Pour ce faire, reportez-vous à la section Mettre en œuvre un 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, consultez les propriétés système pour le chargeur.