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 d'exécuter healthd_mainloop et d'effectuer des interrogations). 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 enregistre IHealth sur hwservicemanager (bien qu'il s'agisse d'un démon système). IHealth est ajouté au manifeste système, avec le nom d'instance « sauvegarde ».
Framework et storaged communiquent avec healthd via hwbinder au lieu de binder .
Le code du framework et storaged est modifié pour récupérer l'instance "par défaut" si disponible, puis "sauvegarde".
- Le code client C++ utilise la logique définie dans libhealthhalutils .
- Le code client Java utilise la logique définie dans HealthServiceWrapper .
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émentation du 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 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 :
- Doit 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, créez un lien statique vers libstoragehealthdefault .
Mettez à jour les autorisations SELinux nécessaires.

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

Clientèle de santé

Voir Clients de santé pour la 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 et storaged d'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 binder.
Supprime les règles qui permettent à healthd d'enregistrer batteryproperties_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 l'intégrité 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 .