Mise en œuvre de Santé 2.1

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 statiquement par health@2.0-impl-2.1 , l'implémentation passthrough de health 2.1. Les bibliothèques lié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, le health@2.1-service enregistre une implémentation de l'interface IHealth auprès de hwservicemanager . Lors de la mise à niveau d'appareils avec une image de fournisseur Android 8.x ou 9 et une infrastructure Android 11, l'image de fournisseur peut ne pas fournir le service health@2.1. La rétrocompatibilité avec les images des anciens fournisseurs est imposée par le calendrier d'obsolescence .

Pour assurer la rétrocompatibilité :

  1. healthd enregistre IHealth sur hwservicemanager bien qu'il s'agisse d'un démon système. IHealth est ajouté au manifeste du système, avec le nom d'instance "sauvegarde".
  2. Le framework et storaged communiquent avec healthd via hwbinder au lieu de binder .
  3. Le code de framework et storaged est modifié pour récupérer l'instance "default" si 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 .
  4. Une fois que IHealth/default est largement disponible et que les images du fournisseur Android 8.1 sont obsolètes, IHealth/backup et healthd peuvent être obsolètes. Pour plus de détails, consultez Dépréciation de health@1.0 .

Variables de construction spécifiques à la carte pour healthd

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

Mise en place du service Santé 2.1

Pour plus d'informations sur l'implémentation du service Health 2.1, voir hardware/interfaces/health/2.1/README.md .

Clients de la santé

health@2.x a les clients suivants :

  • chargeur . L'utilisation de libbatterymonitor et du code healthd_common est encapsulée dans health@2.0-impl .
  • 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 .

  • Gestionnaire de batterie . BatteryManager.queryProperty(int id) était le seul client de IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty a été fourni par healthd et lit directement /sys/class/power_supply .

    Pour des raisons de sécurité, les applications ne sont pas autorisées à appeler directement HAL de santé. Dans Android 9 et versions ultérieures, le service de classeur IBatteryPropertiesRegistrar est fourni par BatteryService au lieu de healthd . BatteryService délègue l'appel à la santé HAL pour récupérer les informations demandées.

  • Service de batterie . 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 du vendor ou utiliser l'instance de service de santé de sauvegarde de healthd . BatteryService écoute ensuite les événements de santé via IHealth.registerCallback .

  • Stocké . 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 du vendor ou utiliser 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.

Changements de SELinux

La 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 avec leur propre implémentation, certaines modifications du fournisseur SELinux 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 noyau suivantes pour récupérer les informations sur la batterie :

  • /sys/class/power_supply/*/capacity_level (ajouté dans la 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 la 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 la santé 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Toute implémentation HAL d'intégrité spécifique à un périphérique qui utilise libbatterymonitor accède à ces interfaces de noyau par défaut, sauf si elle est remplacée dans le constructeur de classe d'implémentation d'intégrité.

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 politique SELinux mal configurée), ils peuvent ne pas fonctionner correctement. Par conséquent, des modifications supplémentaires de SELinux 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. Cependant, pour éviter des comportements de framework incorrects résultant d'interfaces de noyau manquantes, il est recommandé de sélectionner CL 1398913 avant de créer le service de santé HAL 2.1.

Essai

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

Exigences relatives aux informations sur la batterie

La santé 2.0 HAL énonce un ensemble d'exigences sur 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. Spécifiquement:
    • courant == 0 lorsque l'état de la batterie est UNKNOWN
    • courant > 0 lorsque l'état de la batterie est CHARGING
    • courant <= 0 lorsque l'état de la batterie est NOT_CHARGING
    • courant < 0 lorsque l'état de la batterie est DISCHARGING
    • Non appliqué lorsque l'état de la batterie est FULL
  • L'état de la batterie doit être correct, qu'une source d'alimentation soit connectée ou non. Spécifiquement:
    • 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 transmettez les valeurs des interfaces du noyau, assurez-vous que les nœuds sysfs signalent les valeurs correctes :

  • Assurez-vous que le courant de la batterie est signalé avec le signe et les unités corrects. 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 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 1000 et rapporte les valeurs en millivolts (mV). Voir @1.0::InfoSanté .

Pour plus de détails, voir Classe d'alimentation Linux .