Implémenter Health 2.1

Dans Android 11, tout le code healthd est refactorisé en libhealthloop et libhealth2impl, puis modifiés pour implémenter la classe health@2.1 CARL. Ces deux bibliothèques sont liées de manière statique par health@2.0-impl-2.1, l'implémentation passthrough de Health 2.1. Les bibliothèques liées de manière statique activer health@2.0-impl-2.1 pour qu'il effectue le même travail que healthd, comme exécuter healthd_mainloop et la scrutation. Dans init, health@2.1-service enregistre Implémentation de l'interface IHealth vers hwservicemanager. Lors de la mise à niveau les appareils équipés d'Android 8.x ou 9 une image du fournisseur et un framework Android 11, il est possible que l'image du fournisseur ne fournisse pas le service health@2.1. Arrière la compatibilité avec les anciennes images de fournisseurs est appliquée planning d'abandon.

Pour assurer la rétrocompatibilité:

  1. healthd enregistre IHealth dans hwservicemanager bien qu'il s'agisse d'un système le daemon. IHealth est ajouté au fichier manifeste du système, avec le nom de l'instance. "sauvegarde".
  2. Le framework et storaged communiquent avec healthd via hwbinder au lieu de binder.
  3. Le code du framework et de storaged sont modifiés afin de récupérer l'instance "par défaut" s'il est disponible, alors "sauvegarde".
    • Le code client C++ utilise la logique définie dans libhealthhalutils.
    • Le code client Java utilise la logique définie dans HealthServiceWrapper.
  4. Après la mise à disposition générale d'IHealth/default et la disponibilité des images des fournisseurs Android 8.1 obsolète, IHealth/backup et healthd peuvent être abandonnés. Pour plus détails, consultez Abandon de health@1.0.

Variables de compilation spécifiques au plateau pour "healthd"

Les BOARD_PERIODIC_CHORES_INTERVAL_* sont des variables spécifiques au tableau utilisées pour créer healthd Dans le cadre de la division du build système/fournisseur, valeurs spécifiques aux cartes ne peut pas être défini pour les modules système. Auparavant, 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 périodique des tâches dans la structure healthd_config avant au constructeur de la classe d'implémentation de la santé. L'état la classe d'implémentation doit hériter android::hardware::health::V2_1::implementation::Health

Implémenter le service Health 2.1

Pour en savoir plus sur l'implémentation du service Santé 2.1, consultez hardware/interfaces/health/2.1/README.md.

Clients de santé

health@2.x a les clients suivants:

  • du chargeur. L'utilisation des codes libbatterymonitor et healthd_common est encapsulé dans health@2.0-impl.
  • de récupération. Le lien avec libbatterymonitor est encapsulé health@2.0-impl Tous les appels à BatteryMonitor sont remplacés par des appels dans la classe d'implémentation Health.

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

    Pour des raisons de sécurité, les applis ne sont pas autorisées à appeler l'HAL de l'état directement. Dans Android 9 ou version ultérieure, le binder le service 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.

  • BatterieService Sur Android 9 et versions ultérieures, BatteryService utilise HealthServiceWrapper pour déterminer s'il faut utiliser Instance de service Health default depuis vendor ou pour utiliser la sauvegarde Compute Engine depuis healthd. BatteryService écoute ensuite événements de santé via IHealth.registerCallback.

  • Espace de stockage. Sur Android 9 et versions ultérieures, storaged utilise libhealthhalutils pour déterminer s'il faut utiliser Instance de service Health default depuis vendor ou pour utiliser la sauvegarde Compute Engine depuis healthd. storaged, puis écoute les événements de santé via IHealth.registerCallback et récupère des informations sur le stockage.

Modifications apportées à SELinux

Le HAL health@2.1 inclut les modifications SELinux suivantes apportées à la plate-forme:

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

Pour les appareils disposant de leur propre implémentation, certaines modifications de 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 kernel

Le daemon healthd et l'implémentation par défaut android.hardware.health@2.0-impl-2.1 accède aux interfaces de noyau suivantes pour 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 spécifique à l'appareil qui utilise libbatterymonitor accède à ces interfaces de noyau par défaut, sauf s'il est remplacé dans les paramètres de classe d'implémentation.

Si ces fichiers sont manquants ou sont 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 règle SELinux mal configurée), il est possible qu'il fonctionne correctement. D'autres modifications de SELinux propres aux fournisseurs peuvent donc être 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 peut être facultatif. Toutefois, pour éviter les comportements de framework incorrects dus à l'absence d'interfaces de noyau nous vous recommandons de sélectionner CL 1398913 avant de créer le service Health HAL 2.1.

Tests

Android 11 inclut de nouveaux Tests VSS spécialement conçue pour le 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. Les tests sont écrits pour l'instance par défaut (pour garantir que l'appareil implémente correctement le HAL) et l'instance de sauvegarde (pour garantir que healthd continue de fonctionner correctement avant d'être supprimée).

Exigences concernant les informations sur la batterie

Le HAL de Santé 2.0 indique 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 s'appliquent aux appareils lancés avec Android 11 et versions ultérieures:

  • Les unités de courant intatanique et moyen de la batterie doivent être exprimées en microampères (μA).
  • Le signe du courant instantané et du courant moyen de la batterie doit être correct. Plus précisément: <ph type="x-smartling-placeholder">
      </ph>
    • actuel == 0 quand l'état de la batterie est UNKNOWN
    • actuel > 0 lorsque l'état de la batterie est CHARGING
    • actuel <= 0 lorsque l'état de la batterie est NOT_CHARGING
    • actuel < 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 selon que la source d'alimentation connectés. Plus précisément: <ph type="x-smartling-placeholder">
      </ph>
    • l'état de la batterie doit être CHARGING, NOT_CHARGING ou FULL si et uniquement si une source d’alimentation est branchée ;
    • l'état de la batterie doit être DISCHARGING si et seulement si une source d'alimentation est déconnectés.

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

  • Assurez-vous que l'intensité du courant de la batterie est indiquée avec le bon symbole de signal et d'unités. Ce inclut les nœuds sysfs suivants: <ph type="x-smartling-placeholder">
      </ph>
    • /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).
  • Vérifiez que la tension de la batterie est exprimée en microvolts (μV). Cela inclut les nœuds sysfs suivants: <ph type="x-smartling-placeholder">
      </ph>
    • /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). Voir @1.0::InfosSanté

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