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

Implémenter Health 2.0

L'ensemble du code healthd a été refactorisé en health@2.0-impl et libhealthservice, puis modifié pour implémenter health@2.0 HAL. Ces deux les bibliothèques sont liées de manière statique par "health@2.0-service", ce qui lui permet le travail effectué précédemment par healthd (c'est-à-dire, exécuter healthd_mainloop et exécuter lors des interrogations). Lors de l'initialisation, la commande "health@2.0-service" enregistre une implémentation de la l'interface IHealth vers hwservicemanager. Lors de la mise à niveau d'appareils Image du fournisseur Android 8.x et framework Android 9, Le service health@2.0 peut ne pas être fourni par l'image du fournisseur. Application forcée par le planning d'abandon.

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

healthd enregistre IHealth dans hwservicemanager (bien qu'il s'agisse d'un système et le daemon). 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 de storaged sont modifiés afin de 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.
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 , consultez Deprecating health@1.0 (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 système/fournisseur, valeurs spécifiques aux cartes ne peut pas être défini pour les modules système. Dans health@2.0, les fournisseurs peuvent remplacer ces deux valeurs dans healthd_mode_ops->init (en supprimant libhealthservice la dépendance dans health@2.0-service.<device> et la réimplémentation de cette fonction).

Bibliothèque d'implémentation statique

Contrairement aux autres bibliothèques d'implémentation HAL, health@2.0-impl est une bibliothèque statique sur laquelle health@2.0-service, chargeur, la récupération et l'ancien lien opérationnel.

health@2.0.impl implémente IHealth comme décrit ci-dessus et est destiné à encapsuler autour du libbatterymonitor et du libhealthd.BOARD. Ces les utilisateurs de health@2.0-impl ne doivent pas utiliser BatteryMonitor ni les fonctions de libhealthd directement ; Ces appels doivent être remplacés par des appels dans La classe Health, une implémentation de l'interface IHealth. Pour généraliser De plus, le code healthd_common est également inclus dans health@2.0-impl. Les nouvelles healthd_common contient le reste du code commun entre health@2.0-service, chargeur, healthd et appelle les méthodes IHealth au lieu de BatteryMonitor.

Implémenter le service Health 2.0

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

Suffisant pour l'appareil, utilisez android.hardware.health@2.0-service directement.
Pas suffisant pour l'appareil, créez le Exécutable android.hardware.health@2.0-service.(device) et inclut les éléments suivants:
```
#include <health2/service.h>
int main() { return health_service_main(); }
```

Ensuite :

Si libhealthd: est spécifique au tableau
- Existent, créez un lien vers celui-ci.
- N'existe pas, fournissez des implémentations vides pour healthd_board_init et healthd_board_battery_update.
Si des variables BOARD_PERIODIC_CHORES_INTERVAL_* propres à un tableau:
- sont définis, créez un HealthServiceCommon.cpp spécifique à l'appareil (copié) ; de hardware/interfaces/health/2.0/utils/libhealthservice) et personnalisez-la dans healthd_mode_service_2_0_init.
- ne sont pas définis. Créez un lien vers libhealthservice en mode statique.
Si l'appareil:
- Devrait implémenter les API getStorageInfo et getDiskStats, fournir le l'implémentation dans les fonctions get_storage_info et get_disk_stats.
- Ne devrait pas implémenter ces API, associer à libstoragehealthdefault de manière statique.
Mettez à jour les autorisations SELinux nécessaires.

Implémentez HAL dans la reprise en installant une implémentation passthrough dans la de 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 la page Clients Santé pour Health 2.1 HAL.

Modifications apportées à SELinux

Le nouveau HAL health@2.0 inclut les modifications SELinux suivantes:

Ajoute "health@2.0-service" à file_contexts.
Permet à system_server et storaged d'utiliser hal_health.
Autorise system_server (BatteryService) à s'inscrire batteryproperties_service (IBatteryPropertiesRegistrar).
Permet à healthd de fournir hal_health.
Supprime les règles qui autorisent system_server et storaged à appeler healthd via la liaison.
Suppression des règles qui permettent à healthd d'enregistrer batteryproperties_service (IBatteryPropertiesRegistrar).

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/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 kernel

Consultez la section Interfaces de noyau pour HAL Health 2.1.

Tests

Android 9 inclut de nouveaux tests VSS spécialement conçue pour le HAL health@2.0. Si un appareil déclare fournir health@2.0 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

Consultez la section Exigences concernant les informations sur la batterie.