Health 2.0 implementieren

Der gesamte healthd-Code wurde in health@2.0-impl refaktoriert und libhealthservice und anschließend zur Implementierung von health@2.0 HAL geändert. Diese beiden Bibliotheken werden statisch über health@2.0-service verknüpft, zuvor von healthd erledigte Arbeit (d. h. healthd_mainloop ausführen und Abfragen). Bei init registriert der health@2.0-Service eine Implementierung der Schnittstelle IHealth zu hwservicemanager. Wenn Sie Geräte mit einem Anbieter-Image mit Android 8.x und ein Android 9-Framework, Health@2.0-Dienst wird möglicherweise nicht vom Anbieter-Image bereitgestellt. Dies wird erzwungen durch die Zeitplan für die Einstellung.

So lösen Sie dieses Problem:

  1. healthd registriert IHealth bei hwservicemanager (obwohl es sich um ein System handelt) Daemon). IHealth wird dem Systemmanifest mit dem Instanznamen hinzugefügt "backup".
  2. Framework und storaged kommunizieren mit healthd über hwbinder statt binder.
  3. Code für Framework und storaged wurden geändert, um die Instanz abzurufen "default", falls verfügbar, danach "backup".
    • Der C++-Clientcode verwendet die in libhealthhalutils definierte Logik.
    • Der Java-Clientcode verwendet die in HealthServiceWrapper definierte Logik.
  4. Sobald IHealth/default allgemein verfügbar ist und Android 8.1-Anbieter-Images eingestellt, IHealth/backup und healthd können verworfen werden. Weitere Informationen Weitere Informationen finden Sie unter Einstellung von health@1.0.

Board-spezifische Build-Variablen für fehlerfreie

BOARD_PERIODIC_CHORES_INTERVAL_* sind boardspezifische Variablen, die zum Erstellen von healthd. Im Rahmen der Aufteilung zwischen System und Anbieter, nicht für Systemmodule definiert. In Health@2.0 können Anbieter die diese beiden Werte in healthd_mode_ops->init (durch Verwerfen von libhealthservice Abhängigkeit in health@2.0-service.<device> und die erneute Implementierung dieser Funktion).

Statische Implementierungsbibliothek

Im Gegensatz zu anderen HAL-Implementierungsbibliotheken Health@2.0-impl ist eine statische Bibliothek, für die Health@2.0-Service, Ladegerät, Wiederherstellung und alten fehlerfreien Link.

Health@2.0.impl implementiert IHealth wie oben beschrieben und soll umschließen gegen libbatterymonitor und libhealthd.BOARD. Diese dürfen Nutzer von Health@2.0-impl weder BatteryMonitor noch die Funktionen in libhealthd direkt; sollten diese Aufrufe durch Aufrufe in Die Health-Klasse, eine Implementierung des IHealth-Interface Zur Verallgemeinerung Außerdem ist der healthd_common-Code auch in health@2.0-impl enthalten. Das neue healthd_common enthält den Rest des gemeinsamen Codes für health@2.0-service. Ladestation und healthd und ruft IHealth-Methoden anstelle von BatteryMonitor auf.

Health 2.0-Dienst implementieren

bei der Implementierung des Health@2.0-Dienstes für ein Gerät, wenn die Standardimplementierung lautet:

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

  • Nicht ausreichend für das Gerät, erstellen Sie den android.hardware.health@2.0-service.(device) ausführbar und enthält:

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

Dann:

  • Wenn board-spezifisch libhealthd:

    • Existiert, Link zu ihr.
    • Nicht vorhanden, leere Implementierungen für healthd_board_init angeben und healthd_board_battery_update.

  • Wenn boardspezifische BOARD_PERIODIC_CHORES_INTERVAL_*-Variablen:

    • Sind definiert, erstellen Sie ein gerätespezifisches HealthServiceCommon.cpp (kopiert) von hardware/interfaces/health/2.0/utils/libhealthservice) und in healthd_mode_service_2_0_init anpassen.
    • Nicht definiert, Link zu libhealthservice statisch.

  • Bei Gerät:

    • Für die Implementierung der APIs getStorageInfo und getDiskStats sollten Sie die -Implementierung in get_storage_info- und get_disk_stats-Funktionen.
    • Diese APIs sollten nicht implementiert werden. Link zu libstoragehealthdefault statisch werden.

  • Aktualisieren Sie die erforderlichen SELinux-Berechtigungen.

  • Implementieren Sie HAL bei der Wiederherstellung, indem Sie eine Passthrough-Implementierung Wiederherstellungsabbild. 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 Informationen finden Sie unter hardware/interfaces/health/2.0/README.md.

Gesundheitskundschaft

Siehe Health clients for Health 2.1 HAL.

SELinux-Änderungen

Der neue Health@2.0 HAL enthält die folgenden SELinux-Änderungen:

  • Fügt Health@2.0-service zu file_contexts hinzu.
  • Erlaubt system_server und storaged, hal_health zu verwenden.
  • Registrierung von system_server (BatteryService) zulassen batteryproperties_service (IBatteryPropertiesRegistrar).
  • Erlaubt healthd, hal_health bereitzustellen.
  • Entfernt Regeln, die system_server und storaged den Aufruf von healthd durch Binder.
  • Entfernt Regeln, die es healthd ermöglichen, batteryproperties_service zu registrieren (IBatteryPropertiesRegistrar)

Bei Geräten mit eigener Implementierung können einige SELinux-Anbieteränderungen notwendig ist. 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.

Kernelschnittstellen

Siehe Kernel-Schnittstellen für Health 2.1 HAL.

Testen

Android 9 enthält neue VTS-Tests die speziell für die Health@2.0 HAL-Datei entwickelt wurden. Wenn ein Gerät deklariert, state@2.0 HAL im Gerätemanifest auf, muss es die entsprechenden VTS-Tests bestehen. Tests werden sowohl für die Standardinstanz geschrieben, um sicherzustellen, dass das Gerät den HAL korrekt implementiert) und die Sicherungsinstanz, um sicherzustellen, dass healthd weiterhin ordnungsgemäß funktioniert, bevor es entfernt wird).

Anforderungen an Akkuinformationen

Siehe Anforderungen an Akkuinformationen.