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 du fournisseur Android 8.x ou 9 et un framework Android 11, il est possible que l'image du 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
enregistreIHealth
surhwservicemanager
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 avechealthd
viahwbinder
au lieu debinder
. - 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
.
- Le code client C++ utilise la logique définie dans
- 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. 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 du secteur de la santé
health@2.x comporte les clients suivants :
- chargeur. L'utilisation du code
libbatterymonitor
ethealthd_common
est encapsulée danshealth@2.0-impl
. - recovery. Le lien vers
libbatterymonitor
est encapsulé danshealth@2.0-impl
. Tous les appels àBatteryMonitor
sont remplacés par des appels à la classe d'implémentationHealth
. BatteryManager
BatteryManager.queryProperty(int id)
était le seul client deIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
a été fourni parhealthd
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 parBatteryService
au lieu dehealthd
.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
utiliseHealthServiceWrapper
pour déterminer s'il faut utiliser l'instance de service de santé par défaut devendor
ou l'instance de service de santé de sauvegarde dehealthd
.BatteryService
écoute ensuite les événements de santé viaIHealth.registerCallback
.Storaged. Dans Android 9 et versions ultérieures,
storaged
utiliselibhealthhalutils
pour déterminer s'il faut utiliser l'instance de service de santé par défaut devendor
ou l'instance de service de santé de sauvegarde dehealthd
.storaged
écoute ensuite les événements de santé viaIHealth.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, il peut être nécessaire d'apporter certaines modifications SELinux au fournisseur. 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 health@2.1 HAL 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 Health 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
- current == 0 lorsque l'état de la batterie est
- L'état de la batterie doit être correct, selon qu'une source d'alimentation est connectée ou non. Plus précisément :
- l'état de la batterie doit être
CHARGING
,NOT_CHARGING
ouFULL
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.
- l'état de la batterie doit être
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 la bonne unité. 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 un 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.