À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Implémenter Health 2.1

Dans Android 11, tout le code healthd est refactorisé dans libhealthloop et libhealth2impl, puis modifié pour implémenter le HAL health@2.1. Ces deux bibliothèques sont liées de manière statique par health@2.0-impl-2.1, l'implémentation directe de Health 2.1. Les bibliothèques associées de manière statique permettent à health@2.0-impl-2.1 d'effectuer le même travail que healthd, comme l'exécution de healthd_mainloop et l'interrogation. Dans init, health@2.1-service enregistre une implémentation de l'interface IHealth sur hwservicemanager. Lors de la mise à niveau d'appareils avec une image fournisseur Android 8.x ou 9 et un framework Android 11, il est possible que l'image fournisseur ne fournisse pas le service health@2.1. La rétrocompatibilité avec les anciennes images du fournisseur est appliquée par le calendrier d'obsolescence.

Pour assurer la rétrocompatibilité :

healthd enregistre IHealth sur hwservicemanager malgré le fait qu'il s'agisse d'un daemon système. IHealth est ajouté au fichier manifeste système, avec le nom d'instance "backup".
Le framework et storaged communiquent avec healthd via hwbinder au lieu de binder.
Le code du framework et storaged sont modifiés pour récupérer l'instance "default" si elle est disponible, puis "backup".
- Le code client C++ utilise la logique définie dans libhealthhalutils.
- Le code client Java utilise la logique définie dans HealthServiceWrapper.
Une fois que IHealth/default sera largement disponible et que les images du fournisseur Android 8.1 seront obsolètes, IHealth/backup et healthd pourront être abandonnés.

Variables de compilation spécifiques à la carte pour healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sont des variables spécifiques à la carte utilisées pour compiler healthd. Dans le cadre de la séparation de la compilation système/fournisseur, les valeurs spécifiques à la carte ne peuvent pas être définies pour les modules système. Ces valeurs étaient auparavant remplacées dans la fonction obsolète healthd_board_init.

Dans health@2.1, les fournisseurs peuvent remplacer ces deux valeurs d'intervalle de tâches périodiques dans la structure healthd_config avant de les transmettre au constructeur de la classe d'implémentation de l'état de santé. La classe d'implémentation de l'état de santé doit hériter de android::hardware::health::V2_1::implementation::Health.

Implémenter le service Health 2.1

Pour savoir comment implémenter le service Santé 2.1, consultez hardware/interfaces/health/2.1/README.md.

Clients Santé

health@2.x comporte les clients suivants :

chargeur. L'utilisation du code libbatterymonitor et healthd_common est encapsulée dans health@2.0-impl.
recovery. L'association à libbatterymonitor est encapsulée dans health@2.0-impl. Tous les appels à BatteryMonitor sont remplacés par des appels à la classe d'implémentation Health.
BatteryManager BatteryManager.queryProperty(int id) était le seul client de IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty a été fourni par healthd et lu directement /sys/class/power_supply.

Pour des raisons de sécurité, les applications ne sont pas autorisées à appeler directement le HAL de santé. Dans Android 9 et versions ultérieures, le service Binder IBatteryPropertiesRegistrar est fourni par BatteryService au lieu de healthd. BatteryService délègue l'appel au HAL de santé pour récupérer les informations demandées.
BatteryService. Dans Android 9 et versions ultérieures, BatteryService utilise HealthServiceWrapper pour déterminer s'il faut utiliser l'instance de service de santé par défaut de vendor ou l'instance de service de santé de sauvegarde de healthd. BatteryService écoute ensuite les événements de santé via IHealth.registerCallback.
Storaged. Dans Android 9 et versions ultérieures, storaged utilise libhealthhalutils pour déterminer s'il faut utiliser l'instance de service de santé par défaut de vendor ou l'instance de service de santé de sauvegarde de healthd. storaged écoute ensuite les événements de santé via IHealth.registerCallback et récupère les informations de stockage.

Modifications apportées à SELinux

Le HAL health@2.1 inclut les modifications SELinux suivantes dans la plate-forme :

Ajoute android.hardware.health@2.1-service à file_contexts.

Pour les appareils disposant de leur propre implémentation, certaines modifications SELinux du fournisseur peuvent être nécessaires. Exemple :

# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.

Interfaces du noyau

Le démon healthd et l'implémentation par défaut android.hardware.health@2.0-impl-2.1 accèdent aux interfaces du noyau suivantes pour récupérer les informations sur la batterie :

/sys/class/power_supply/*/capacity_level (ajouté dans Santé 2.1)
/sys/class/power_supply/*/capacity
/sys/class/power_supply/*/charge_counter
/sys/class/power_supply/*/charge_full
/sys/class/power_supply/*/charge_full_design (ajouté dans Santé 2.1)
/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
/sys/class/power_supply/*/cycle_count
/sys/class/power_supply/*/health
/sys/class/power_supply/*/online
/sys/class/power_supply/*/present
/sys/class/power_supply/*/status
/sys/class/power_supply/*/technology
/sys/class/power_supply/*/temp
/sys/class/power_supply/*/time_to_full_now (ajouté dans Santé 2.1)
/sys/class/power_supply/*/type
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now

Toute implémentation HAL de l'état de santé spécifique à un appareil qui utilise libbatterymonitor accède à ces interfaces du noyau par défaut, sauf si elle est remplacée dans le constructeur de la classe d'implémentation de l'état de santé.

S'ils sont manquants ou inaccessibles depuis healthd ou depuis le service par défaut (par exemple, si le fichier est un lien symbolique vers un dossier spécifique au fournisseur qui refuse l'accès en raison d'une stratégie SELinux mal configurée), ils risquent de ne pas fonctionner correctement. Des modifications SELinux supplémentaires spécifiques au fournisseur peuvent donc être nécessaires, même si l'implémentation par défaut est utilisée.

Certaines interfaces de noyau utilisées dans Santé 2.1, telles que /sys/class/power_supply/*/capacity_level et /sys/class/power_supply/*/time_to_full_now, peuvent être facultatives. Toutefois, pour éviter les comportements incorrects du framework résultant de l'absence d'interfaces du noyau, il est recommandé de sélectionner CL 1398913 avant de créer le service Health HAL 2.1.

Tests

Android 11 inclut de nouveaux tests VTS écrits spécifiquement pour la HAL health@2.1. Si un appareil déclare le HAL health@2.1 dans le fichier manifeste de l'appareil, il doit réussir les tests VTS correspondants. Des tests sont écrits pour l'instance par défaut (afin de s'assurer que l'appareil implémente correctement la HAL) et pour l'instance de sauvegarde (afin de s'assurer que healthd continue de fonctionner correctement avant d'être supprimé).

Exigences concernant les informations sur la batterie

La HAL Santé 2.0 définit un ensemble d'exigences concernant l'interface HAL, mais les tests VTS correspondants sont relativement souples quant à leur application. Dans Android 11, de nouveaux tests VTS sont ajoutés pour appliquer les exigences suivantes sur les appareils lancés avec Android 11 et versions ultérieures :

Les unités de courant de batterie instantané et moyen doivent être des microampères (μA).
Le signe du courant de batterie instantané et moyen doit être correct. Plus précisément :
- current == 0 lorsque l'état de la batterie est UNKNOWN
- current > 0 lorsque l'état de la batterie est CHARGING
- current <= 0 lorsque l'état de la batterie est NOT_CHARGING
- current < 0 lorsque l'état de la batterie est DISCHARGING
- Non appliquée lorsque l'état de la batterie est FULL
L'état de la batterie doit correspondre à la présence ou à l'absence d'une source d'alimentation. Plus précisément :
- l'état de la batterie doit être CHARGING, NOT_CHARGING ou FULL si et seulement si une source d'alimentation est connectée ;
- L'état de la batterie doit être DISCHARGING si et seulement si une source d'alimentation est déconnectée.

Si vous utilisez libbatterymonitor dans votre implémentation et que vous transmettez des valeurs à partir d'interfaces de noyau, assurez-vous que les nœuds sysfs indiquent les valeurs correctes :

Assurez-vous que le courant de la batterie est indiqué avec le bon signe et les bonnes unités. Cela inclut les nœuds sysfs suivants :
- /sys/class/power_supply/*/current_avg
- /sys/class/power_supply/*/current_max
- /sys/class/power_supply/*/current_now
- Les valeurs positives indiquent le courant entrant dans la batterie.
- Les valeurs doivent être exprimées en microampères (μA).
Assurez-vous que la tension de la batterie est indiquée en microvolts (μV). Cela inclut les nœuds sysfs suivants :
- /sys/class/power_supply/*/voltage_max
- /sys/class/power_supply/*/voltage_now
- Notez que l'implémentation HAL par défaut divise voltage_now par 1 000 et indique les valeurs en millivolts (mV). Consultez @1.0::HealthInfo.

Pour en savoir plus, consultez Classe d'alimentation Linux.