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

Mise en œuvre de la santé 2.0

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 exécuter le healthd_mainloop et effectuer une interrogation). Dans init, le service health@2.0 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 et une infrastructure Android 9, le service health@2.0 peut ne pas être fourni par l'image de fournisseur. Ceci est appliqué par le calendrier de dépréciation .

Pour résoudre ce problème :

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".
Framework et storaged communiquent avec healthd via hwbinder au lieu de binder .
Le code pour 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 .
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 des versions 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 libhealthservice 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 BatteryMonitor ou les fonctions de libhealthd directement ; à la place, 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 health@2.0-service, charger et healthd et appelle les méthodes IHealth au lieu de BatteryMonitor.

Mise en œuvre du service Santé 2.0

Lors de l'implémentation du service health@2.0 pour un appareil, si l'implémentation par défaut est :

Suffisant pour l'appareil, utilisez directement android.hardware.health@2.0-service .
Insuffisant 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(); }
```

Puis:

Si libhealthd:
- Existe-t-il, lien vers celui-ci.
- N'existe pas, fournissez des implémentations vides pour les fonctions healthd_board_init et healthd_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é depuis hardware/interfaces/health/2.0/utils/libhealthservice ) et personnalisez-le dans healthd_mode_service_2_0_init .
- Ne sont pas définis, lien vers libhealthservice de manière statique.
Si appareil :
- Devrait implémenter les API getStorageInfo et getDiskStats , fournir l'implémentation dans les fonctions get_storage_info et get_disk_stats .
- Ne devrait pas implémenter ces API, lien vers libstoragehealthdefault de manière statique.
Mettez à jour les autorisations SELinux nécessaires.

Implémentez HAL dans la récupération en installant une implémentation de relais 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 .

Clients de la santé

Voir Clients de santé pour la santé 2.1 HAL .

Changements de SELinux

La nouvelle HAL health@2.0 inclut les modifications SELinux suivantes :

Ajoute le service health@2.0 à file_contexts .
Autorise system_server et storaged à utiliser hal_health .
Permet system_server ( BatteryService ) d'enregistrer batteryproperties_service ( IBatteryPropertiesRegistrar ).
Permet à healthd de fournir hal_health .
Supprime les règles qui permettent à system_server / storaged d'appeler healthd via un classeur.
Supprime les règles qui permettent à healthd d'enregistrer batteryproperties_service ( IBatteryPropertiesRegistrar ).

Pour les appareils avec leur propre implémentation, certaines modifications du fournisseur SELinux 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 la santé 2.1 HAL .

Essai

Android 9 inclut de nouveaux tests VTS écrits spécifiquement pour le health@2.0 HAL. Si un appareil déclare fournir health@2.0 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

Voir Exigences relatives aux informations sur la batterie .