Implementierung von Gesundheit 2.0

Alle healthd Code in health@2.0-impl und Refactoring worden libhealthservice , dann modifiziert health@2.0 HAL zu implementieren. Diese beiden Bibliotheken sind statisch durch health@2.0-service verknüpft, so dass es die Arbeit zuvor von getan tun healthd (dh führen Sie das healthd_mainloop und tun Polling). In init registriert die health@2.0-service eine Implementierung der Schnittstelle IHealth zu hwservicemanager . Beim Upgrade von Geräten mit einem Android 8.x-Anbieter-Image und einem Android 9-Framework wird der Health@2.0-Dienst möglicherweise nicht vom Anbieter-Image bereitgestellt. Dies wird durch die erzwungene deprecation Zeitplan .

So beheben Sie dieses Problem:

  1. healthd Register IHealth zu hwservicemanager (obwohl es ein System Daemon). IHealth wird das System Manifest hinzugefügt, mit Instanznamen „backup“.
  2. Framework und storaged kommunizieren mit healthd über hwbinder statt binder .
  3. Code für Rahmen und storaged geändert , um die Instanz „default“ , wenn vorhanden, dann „Backup“ zu holen.
    • C ++ Client - Code verwendet die Logik in definierten libhealthhalutils .
    • Java - Client - Code verwendet die Logik definiert in HealthServiceWrapper .
  4. Nach ihealth / default ist weit verbreitet und Android 8.1 Verkäufer Bilder sind veraltet, ihealth / Backup und healthd können veraltet sein. Weitere Einzelheiten finden Sie Deprecating health@1.0 .

Board-spezifische Build-Variablen für healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sind boardspezifischen Variablen zu bauen verwendet healthd . Als Teil des Systems / Kreditoren build Split, baugruppenspezifischen Werte können nicht für die Systemmodule festgelegt werden. In health@2.0 können Anbieter außer Kraft setzen diese beiden Werte in healthd_mode_ops->init (durch Fallenlassen libhealthservice Abhängigkeit in health@2.0-service.<device> und Re-Implementierung dieser Funktion).

Statische Implementierungsbibliothek

Im Gegensatz zu anderen HAL Implementierung Bibliotheken ist die Implementierung Bibliothek health@2.0-impl eine statische Bibliothek , auf die health@2.0-service, Ladegerät, Recovery und Vermächtnis healthd Link.

health@2.0.impl implementiert IHealth wie oben beschrieben und soll umschlingen libbatterymonitor und libhealthd. BOARD . Diese Benutzer von health@2.0-impl dürfen nicht verwenden BatteryMonitor oder die Funktionen in libhealthd direkt; Stattdessen sollten diese Anrufe bei Anrufen in die Fassung Health Klasse, eine Implementierung der IHealth Schnittstelle. Zu verallgemeinern weiter healthd_common ist Code auch in health@2.0-impl enthalten. Die neue healthd_common enthält den Rest des gemeinsamen Code zwischen health@2.0-service, Ladegerät, und healthd und Anrufen in ihealth Methoden statt BatteryMonitor.

Implementierung des Health 2.0-Dienstes

Bei der Implementierung des health@2.0-Dienstes für ein Gerät, wenn die Standardimplementierung wie folgt lautet:

  • Ausreichend für das Gerät verwenden android.hardware.health@2.0-service direkt.

  • Nicht ausreichend für das Gerät, erstellen Sie die android.hardware.health@2.0-service.(device) Ausführbare Datei und schließen ein :

    #include <health2/service.h>
int main() { return health_service_main(); }

Dann:

  • Wenn boardspezifischen libhealthd:

    • Gibt es, verlinke darauf.
    • Existiert nicht bieten leere Implementierungen für healthd_board_init und healthd_board_battery_update Funktionen.

  • Wenn boardspezifischen BOARD_PERIODIC_CHORES_INTERVAL_* Variablen:

    • Definiert, erstellen Sie eine gerätespezifische HealthServiceCommon.cpp (kopiert von hardware/interfaces/health/2.0/utils/libhealthservice ) und passen Sie es in healthd_mode_service_2_0_init .
    • Nicht definiert sind , Link zu libhealthservice statisch.

  • Wenn Gerät:

    • Sollte implementieren getStorageInfo und getDiskStats APIs bieten die Umsetzung in get_storage_info und get_disk_stats Funktionen.
    • Sollte nicht diese APIs implementieren, eine Verknüpfung libstoragehealthdefault statisch.

  • Aktualisieren Sie die erforderlichen SELinux-Berechtigungen.

  • Implementieren Sie HAL in der Wiederherstellung, indem Sie eine Passthrough-Implementierung für das Wiederherstellungsimage installieren. Beispiel:

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

Weitere Einzelheiten finden Sie unter Hardware / Schnittstellen / Gesundheit / 2.0 / README.md .

Gesundheitskunden

Siehe Gesundheit Kunden für die Gesundheit 2.1 HAL .

SELinux-Änderungen

Die neue health@2.0 HAL enthält die folgenden SELinux-Änderungen:

  • Fügt health@2.0-service zu file_contexts .
  • Ermöglicht system_server und storaged Gebrauch hal_health .
  • Ermöglicht system_server ( BatteryService ) registrieren batteryproperties_service ( IBatteryPropertiesRegistrar ).
  • Ermöglicht healthd bereitzustellen hal_health .
  • Beseitigt Regeln, mit denen system_server / storaged ins Leben rufen healthd über Bindemittel.
  • Beseitigt Regeln, mit denen healthd registrieren batteryproperties_service ( IBatteryPropertiesRegistrar ).

Bei Geräten mit eigener Implementierung können einige SELinux-Änderungen des Herstellers erforderlich sein. Beispiel:

# 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.

Kernel-Schnittstellen

Siehe Kernel - Schnittstellen für die Gesundheit 2.1 HAL .

Testen

Android 9 enthält neue VTS - Tests speziell für die health@2.0 HAL geschrieben. Wenn ein Gerät im Gerätemanifest angibt, health@2.0 HAL bereitzustellen, muss es die entsprechenden VTS-Tests bestehen. Die Tests werden sowohl für die Standardinstanz geschrieben (um sicherzustellen , dass das Gerät implementiert die HAL korrekt) und die Backup - Instanz (um sicherzustellen , dass healthd zu funktionieren weiterhin korrekt , bevor sie entfernt wird).

Anforderungen an Batterieinformationen

Siehe Batterie Informationsanforderungen .