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

Implémenter Health 2.0

Tout le code healthd a été refactorisé en health@2.0-impl et libhealthservice, puis modifié pour implémenter le HAL health@2.0. Ces deux bibliothèques sont liées de manière statique par health@2.0-service, ce qui lui permet d'effectuer le travail précédemment effectué par healthd (c'est-à-dire exécuter healthd_mainloop et effectuer l'interrogation). Lors de l'initialisation, le service health@2.0 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 et un framework Android 9, le service health@2.0 peut ne pas être fourni par l'image du fournisseur. Cette règle est appliquée par le calendrier d'abandon.

Pour remédier à ce problème, procédez comme suit :

healthd enregistre IHealth dans hwservicemanager (bien qu'il s'agisse d'un daemon 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 storaged sont modifiés pour extraire 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 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 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 division du build système/fournisseur, les valeurs spécifiques aux cartes 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 vers laquelle "health@2.0-service", "chargeur", "recovery" et l'ancien lien "healthd".

health@2.0.impl implémente IHealth comme décrit ci-dessus et est destinée à encapsuler libbatterymonitor et libhealthd.BOARD. Ces utilisateurs de health@2.0-impl ne doivent pas utiliser directement BatteryMonitor ni les fonctions de libhealthd. À la place, ces appels doivent être remplacés par des appels à 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, chargeur et healthd, et appelle les méthodes IHealth au lieu de BatteryMonitor.

Implémenter le service Santé 2.0

Lorsque vous implémentez le service health@2.0 pour un appareil, si l'implémentation par défaut est:

Suffisamment pour l'appareil, utilisez directement android.hardware.health@2.0-service.
Espace insuffisant pour l'appareil. Créez l'exécutable android.hardware.health@2.0-service.(device) et incluez les éléments suivants:
```
#include <health2/service.h>
int main() { return health_service_main(); }
```

Ensuite :

Si libhealthd: est spécifique au tableau
- Il existe, associez-le.
- N'existe pas, fournit des implémentations vides pour les fonctions healthd_board_init et healthd_board_battery_update.
Si des variables BOARD_PERIODIC_CHORES_INTERVAL_* spécifiques à la carte:
- sont définis, créez un HealthServiceCommon.cpp spécifique à l'appareil (copié à partir de hardware/interfaces/health/2.0/utils/libhealthservice) et personnalisez-le dans healthd_mode_service_2_0_init.
- Ne sont pas définis, associez-les de manière statique à libhealthservice.
Si l'appareil:
- Doit implémenter les API getStorageInfo et getDiskStats, fournir l'implémentation dans les fonctions get_storage_info et get_disk_stats.
- Vous ne devez pas implémenter ces API. Associez-les à libstoragehealthdefault de manière statique.
Mettez à jour les autorisations SELinux nécessaires.

Implémentez HAL en mode récupération en installant une implémentation de passthrough dans 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 en savoir plus, consultez hardware/interfaces/health/2.0/README.md.

Clients de santé

Consultez Clients Santé pour HAL Santé 2.1.

Modifications apportées à 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 autorisent system_server et storaged à appeler healthd via le liaisonneur.
Supprime les règles qui autorisent healthd à enregistrer batteryproperties_service (IBatteryPropertiesRegistrar).

Pour les appareils disposant 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

Consultez la section Interfaces du noyau pour le HAL Santé 2.1.

Tests

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

Consultez les Exigences concernant les informations sur la batterie.