Health 2.0 implementieren

Der gesamte healthd-Code wurde in „health@2.0-impl“ und libhealthservice umgeschrieben und dann so geändert, dass die health@2.0 HAL implementiert wurde. Diese beiden Bibliotheken sind vom health@2.0-Dienst statisch verknüpft, sodass er die Arbeit übernehmen kann, die zuvor von healthd ausgeführt wurde, d. h. healthd_mainloop ausführen und Polling durchführen. In der Initialisierung registriert der health@2.0-Dienst eine Implementierung der Schnittstelle IHealth bei hwservicemanager. Beim Upgrade von Geräten mit einem Android 8.x-Anbieter-Image und einem Android 9-Framework wird der Dienst „health@2.0“ möglicherweise nicht vom Anbieter-Image bereitgestellt. Dies wird durch den Zeitplan für die Einstellung erzwungen.

So lösen Sie dieses Problem:

  1. healthd registriert IHealth bei hwservicemanager (obwohl es sich um einen System-Daemon handelt). IHealth wird dem Systemmanifest mit dem Instanznamen "backup" hinzugefügt.
  2. Framework und storaged kommunizieren mit healthd über hwbinder anstelle von binder.
  3. Der Code für das Framework und storaged wird geändert, um die Instanz "default" abzurufen, falls verfügbar, andernfalls "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-Anbieterbilder eingestellt werden, können IHealth/backup und healthd eingestellt werden. Weitere Informationen finden Sie unter Einstellung von „health@1.0“.

Boardspezifische Buildvariablen für healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sind boardspezifische Variablen, die zum Erstellen von healthd verwendet werden. Im Rahmen des System-/Anbieter-Build-Splits können für Systemmodule keine boardspezifischen Werte definiert werden. In Health@2.0 können Anbieter diese beiden Werte in healthd_mode_ops->init überschreiben, indem sie die libhealthservice-Abhängigkeit in health@2.0-service.<device> entfernen und diese Funktion noch einmal implementieren.

Statische Implementierungsbibliothek

Im Gegensatz zu anderen HAL-Implementierungsbibliotheken ist die Implementierungsbibliothek „health@2.0-impl“ eine statische Bibliothek, mit der der health@2.0-Dienst, das Ladegerät, die Wiederherstellung und der alte healthd verknüpft sind.

Health@2.0.impl implementiert IHealth wie oben beschrieben und soll libbatterymonitor und libhealthd.BOARD umschließen. Diese Nutzer von health@2.0-impl dürfen BatteryMonitor oder die Funktionen in libhealthd nicht direkt verwenden. Stattdessen sollten diese Aufrufe durch Aufrufe der Klasse Health ersetzt werden, einer Implementierung derIHealth-Schnittstelle. Zur weiteren Verallgemeinerung ist der healthd_common-Code auch in health@2.0-impl enthalten. Die neue healthd_common enthält den Rest des gemeinsamen Codes zwischen dem health@2.0-Dienst, dem Ladegerät 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 wie folgt lautet:

  • Das ist für das Gerät ausreichend. Verwende android.hardware.health@2.0-service direkt.

  • Nicht für das Gerät geeignet. Erstellen Sie die ausführbare Datei android.hardware.health@2.0-service.(device) und fügen Sie Folgendes hinzu:

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

Gehen Sie anschließend so vor:

  • Wenn unternehmensspezifisch libhealthd:

    • Existiert, Link zu ihr.
    • Gibt es nicht, geben Sie leere Implementierungen für die Funktionen healthd_board_init und healthd_board_battery_update an.

  • Wenn BOARD_PERIODIC_CHORES_INTERVAL_*-Variablen für das Board:

    • definiert sind, erstellen Sie ein gerätespezifisches HealthServiceCommon.cpp (aus hardware/interfaces/health/2.0/utils/libhealthservice kopiert) und passen Sie es in healthd_mode_service_2_0_init an.
    • Sie sind nicht definiert. Verknüpfen Sie sie statisch mit libhealthservice.

  • Wenn das Gerät:

    • Wenn Sie die APIs getStorageInfo und getDiskStats implementieren, geben Sie die Implementierung in den Funktionen get_storage_info und get_disk_stats an.
    • Wenn diese APIs nicht implementiert werden, verknüpfen Sie sie statisch mit libstoragehealthdefault.

  • Aktualisieren Sie die erforderlichen SELinux-Berechtigungen.

  • Implementieren Sie HAL bei 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 Informationen finden Sie unter hardware/interfaces/health/2.0/README.md.

Gesundheitskundschaft

Weitere Informationen finden Sie unter Health-Clients für Health 2.1 HAL.

SELinux-Änderungen

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

  • Dem Nutzer file_contexts wird der Dienst „health@2.0“ hinzugefügt.
  • Ermöglicht es system_server und storaged, hal_health zu verwenden.
  • Ermöglicht system_server (BatteryService) die Registrierung von batteryproperties_service (IBatteryPropertiesRegistrar).
  • Ermöglicht es healthd, hal_health bereitzustellen.
  • Entfernt Regeln, die es system_server und storaged ermöglichen, über Binder auf healthd zuzugreifen.
  • Entfernt Regeln, die es healthd ermöglichen, batteryproperties_service (IBatteryPropertiesRegistrar) zu registrieren.

Bei Geräten mit eigener Implementierung sind möglicherweise einige SELinux-Änderungen des Anbieters erforderlich. 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

Weitere Informationen finden Sie unter 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 entwickelt wurden. Wenn ein Gerät im Gerätemanifest angibt, dass es die HAL „health@2.0“ bereitstellt, muss es die entsprechenden VTS-Tests bestehen. Tests werden sowohl für die Standardinstanz als auch für die Sicherungsinstanz geschrieben, um sicherzustellen, dass das Gerät den HAL korrekt implementiert. So wird sichergestellt, dass healthd vor dem Entfernen weiterhin korrekt funktioniert.

Anforderungen an Akkuinformationen

Weitere Informationen finden Sie unter Anforderungen an Akkuinformationen.