Tout le code healthd
a été refactorisé dans health@2.0-impl et libhealthservice
, puis modifié pour implémenter health@2.0 HAL. Ces deux bibliothèques sont liées statiquement par le service health@2.0, ce qui lui permet d'effectuer le travail précédemment effectué par healthd
(c'est-à-dire d'exécuter healthd_mainloop
et d'effectuer une interrogation). Dans init, le service health@2.0 enregistre une implémentation de l'interface IHealth
vers hwservicemanager
. Lors de la mise à niveau d'appareils avec une image du fournisseur Android 8.x et un framework Android 9, le service health@2.0 peut ne pas être fourni par l'image du fournisseur. Ceci est renforcé par le calendrier de dépréciation .
Pour résoudre ce problème :
-
healthd
enregistreIHealth
surhwservicemanager
(bien qu'il s'agisse d'un démon système).IHealth
est ajouté au manifeste système, avec le nom d'instance"backup"
. - Framework et
storaged
communiquent avechealthd
viahwbinder
au lieu debinder
. - Le code du 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
.
- Le code client C++ utilise la logique définie dans
- Une fois qu’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 créer healthd
. Dans le cadre de la répartition de la construction système/fournisseur, les valeurs spécifiques à la carte ne peuvent pas être définies pour les modules système. Dans health@2.0, les fournisseurs peuvent remplacer ces deux valeurs dans healthd_mode_ops->init
(en supprimant la dépendance libhealthservice
dans health@2.0-service.<device>
et en réimplémentant cette fonction).
Bibliothèque d'implémentation statique
Contrairement aux autres bibliothèques d'implémentation HAL, la bibliothèque d'implémentation health@2.0-impl est une bibliothèque statique à laquelle health@2.0-service, charger, recovery et Legacy healthd sont liés.
health@2.0.impl implémente IHealth
comme décrit ci-dessus et est destiné à envelopper libbatterymonitor
et libhealthd. BOARD
. Ces utilisateurs de health@2.0-impl ne doivent pas utiliser directement BatteryMonitor
ou les fonctions de libhealthd
; au lieu de cela, ces appels doivent être remplacés par des appels dans la classe Health
, une implémentation de l'interface IHealth
. Pour généraliser davantage, le code healthd_common
est également inclus dans health@2.0-impl. Le nouveau healthd_common
contient le reste du code commun entre le service health@2.0, le chargeur et healthd
et appelle les méthodes IHealth au lieu de BatteryMonitor.
Implémenter le service Santé 2.0
Lors de la mise en œuvre du service health@2.0 pour un appareil, si la mise en œuvre par défaut est :
- Suffisant pour l'appareil, utilisez directement
android.hardware.health@2.0-service
. Cela ne suffit pas pour l'appareil, créez l'exécutable
android.hardware.health@2.0-service.(device)
et incluez :#include <health2/service.h> int main() { return health_service_main(); }
Alors:
Si
libhealthd:
- Existe-t-il, créez un lien vers celui-ci.
- N'existe pas, fournissez des implémentations vides pour les fonctions
healthd_board_init
ethealthd_board_battery_update
.
Si les variables
BOARD_PERIODIC_CHORES_INTERVAL_*
spécifiques à la carte :- Sont définis, créez un
HealthServiceCommon.cpp
spécifique à l'appareil (copié depuishardware/interfaces/health/2.0/utils/libhealthservice
) et personnalisez-le danshealthd_mode_service_2_0_init
. - Ne sont pas définis, lien vers
libhealthservice
de manière statique.
- Sont définis, créez un
Si appareil :
- Doit implémenter les API
getStorageInfo
etgetDiskStats
, fournir l'implémentation dans les fonctionsget_storage_info
etget_disk_stats
. - Vous ne devriez pas implémenter ces API, créez un lien statique vers
libstoragehealthdefault
.
- Doit implémenter les API
Mettez à jour les autorisations SELinux nécessaires.
Implémentez HAL lors de la récupération en installant une implémentation passthrough sur l'image de récupération. Exemple:
// Android.bp cc_library_shared { name: "android.hardware.health@2.0-impl-<device>", recovery_available: true, relative_install_path: "hw", static_libs: [ "android.hardware.health@2.0-impl", "libhealthd.<device>" // Include the following or implement device-specific storage APIs "libhealthstoragedefault", ], srcs: [ "HealthImpl.cpp", ], overrides: [ "android.hardware.health@2.0-impl-default", ], }
// HealthImpl.cpp #include <health2/Health.h> #include <healthd/healthd.h> using android::hardware::health::V2_0::IHealth; using android::hardware::health::V2_0::implementation::Health; extern "C" IHealth* HIDL_FETCH_IHealth(const char* name) { const static std::string providedInstance{"default"}; if (providedInstance != name) return nullptr; return Health::initInstance(&gHealthdConfig).get(); }
# device.mk PRODUCT_PACKAGES += android.hardware.health@2.0-impl-<device>
Pour plus de détails, reportez-vous à hardware/interfaces/health/2.0/README.md .
Clientèle de la santé
Voir Clients Santé pour Santé 2.1 HAL .
Modifications de SELinux
Le nouveau HAL health@2.0 inclut les modifications SELinux suivantes :
- Ajoute le service health@2.0 à
file_contexts
. - Permet
system_server
etstoraged
d'utiliserhal_health
. - Permet
system_server
(BatteryService
) d'enregistrerbatteryproperties_service
(IBatteryPropertiesRegistrar
). - Permet
healthd
de fournirhal_health
. - Supprime les règles qui permettent à
system_server
etstoraged
d'appelerhealthd
via binder. - Supprime les règles qui permettent à
healthd
d'enregistrerbatteryproperties_service
(IBatteryPropertiesRegistrar
).
Pour les appareils dotés de leur propre implémentation, certaines modifications SELinux du fournisseur peuvent être nécessaires. Exemple:
# device/<manufacturer>/<device>/sepolicy/vendor/file_contexts
/vendor/bin/hw/android\.hardware\.health@2\.0-service.<device> u:object_r:hal_health_default_exec:s0
# 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
Voir Interfaces du noyau pour Health 2.1 HAL .
Essai
Android 9 inclut de nouveaux tests VTS écrits spécifiquement pour le HAL health@2.0. Si un appareil déclare fournir health@2.0 HAL dans le 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 garantir que le périphérique implémente correctement le HAL) et pour l'instance de sauvegarde (pour garantir que healthd
continue de fonctionner correctement avant d'être supprimé).
Exigences en matière d'informations sur la batterie
Voir Exigences en matière d'informations sur la batterie .