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

Implémenter Health 2.1

Dans Android 11, tout le code healthd est refactorisé en 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 de passthrough de Santé 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, par exemple en exécutant healthd_mainloop et en effectuant des requêtes. Lors de l'initialisation, health@2.1-service enregistre une implémentation de l'interface IHealth dans 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 de fournisseurs est appliquée par le planning d'abandon.

Pour assurer la rétrocompatibilité:

healthd enregistre IHealth dans hwservicemanager, bien qu'il s'agisse d'un démon 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 de storaged est modifié afin de récupérer l'instance "default" (par défaut) si disponible, puis "backup" (sauvegarde).
- 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. Pour en savoir plus, consultez la page Obsolète health@1.0.

Variables de compilation spécifiques à la carte pour healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sont des variables spécifiques à la carte utilisées pour créer healthd. Dans le cadre de la répartition 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 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 passer au constructeur de la classe d'implémentation de la santé. La classe d'implémentation de la santé doit hériter de android::hardware::health::V2_1::implementation::Health.

Implémenter le service Santé 2.1

Pour en savoir plus sur la mise en œuvre du service Health 2.1, consultez la page hardware/interfaces/health/2.1/README.md.

Clients de santé

health@2.x dispose des clients suivants:

chargeur. L'utilisation du code libbatterymonitor et healthd_common est encapsulée dans health@2.0-impl.
de récupération. Le lien vers libbatterymonitor est encapsulé 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 a 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é. Sous Android 9 et versions ultérieures, le service de liaison IBatteryPropertiesRegistrar est fourni par BatteryService au lieu de healthd. BatteryService délègue l'appel à l'HAL de l'état 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é backup de healthd. BatteryService écoute ensuite les événements de santé via IHealth.registerCallback.
Stocké. Sous Android 9 et versions ultérieures, storaged utilise libhealthhalutils pour déterminer si l'instance de service de santé par défaut doit être utilisée à partir de vendor ou si l'instance de service de santé de secours doit être utilisée à partir de healthd. storaged écoute ensuite les événements de santé via IHealth.registerCallback et récupère des 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 daemon healthd et l'implémentation par défaut android.hardware.health@2.0-impl-2.1 accèdent aux interfaces de kernel suivantes pour récupérer des 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 santé spécifique à l'appareil qui utilise libbatterymonitor accède à ces interfaces de noyau par défaut, sauf si elles sont remplacées dans le constructeur de la classe d'implémentation de la santé.

Si ces fichiers sont manquants ou inaccessibles depuis healthd ou depuis le service par défaut (par exemple, 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. Par conséquent, des modifications SELinux supplémentaires spécifiques au fournisseur peuvent être nécessaires, même si l'implémentation par défaut est utilisée.

Certaines interfaces de noyau utilisées dans Health 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 d'interfaces de kernel manquantes, 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 le 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. Les tests sont écrits à la fois pour l'instance par défaut (pour s'assurer que l'appareil implémente correctement le HAL) et pour l'instance de sauvegarde (pour garantir que healthd continue de fonctionner correctement avant sa suppression).

Exigences concernant les informations sur la batterie

Le HAL Health 2.0 établit un ensemble d'exigences sur l'interface HAL, mais les tests VTS correspondants sont relativement souples pour les appliquer. Dans Android 11, de nouveaux tests VTS sont ajoutés pour appliquer les exigences suivantes sur les appareils lancés avec Android 11 ou version ultérieure:

Les unités du courant instantané et moyen de la batterie doivent être les microampères (μA).
Le signe du courant instantané et du courant moyen de la batterie 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 être correct, que la source d'alimentation soit connectée ou non. 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ébranché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 signalent des valeurs correctes:

Assurez-vous que le courant de la batterie est indiqué avec le signe et les unités approprié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 signale les valeurs en millivolts (mV). Voir @1.0::HealthInfo.

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