Gesundheit 2.0 umsetzen

Der gesamte healthd Code wurde in „health@2.0-impl“ und libhealthservice umgestaltet und dann geändert, um „health@2.0 HAL“ zu implementieren. Diese beiden Bibliotheken werden durch den Health@2.0-Service statisch verknüpft, sodass dieser die Arbeit erledigen kann, die zuvor von healthd erledigt wurde (dh den healthd_mainloop ausführen und Abfragen durchführen). In init registriert der 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 Dienst „health@2.0“ möglicherweise nicht vom Anbieter-Image bereitgestellt. Dies wird durch den Verfallsplan erzwungen.

So beheben 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 statt über binder .
  3. Der Code für Framework und storaged wird geändert, um die Instanz „default“ abzurufen, falls verfügbar, und dann „backup“.
    • C++-Clientcode verwendet die in libhealthhalutils definierte Logik.
    • Der Java-Clientcode verwendet die in HealthServiceWrapper definierte Logik.
  4. Nachdem IHealth/default allgemein verfügbar ist und Android 8.1-Anbieterimages veraltet sind, können IHealth/backup und healthd veraltet sein. Weitere Einzelheiten finden Sie unter „Veralten von Health@1.0“ .

Boardspezifische Build-Variablen für healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sind Board-spezifische Variablen, die zum Erstellen healthd verwendet werden. Im Rahmen der System-/Hersteller-Build-Aufteilung können für Systemmodule keine platinenspezifischen Werte definiert werden. In „health@2.0“ können Anbieter diese beiden Werte in healthd_mode_ops->init überschreiben (indem sie libhealthservice Abhängigkeit in health@2.0-service.<device> löschen und diese Funktion erneut implementieren).

Statische Implementierungsbibliothek

Im Gegensatz zu anderen HAL-Implementierungsbibliotheken ist die Implementierungsbibliothek „health@2.0-impl“ eine statische Bibliothek, auf die „health@2.0-service“, „charger“, „recovery“ und „Legacy-healthd“ verweisen.

health@2.0.impl implementiert IHealth wie oben beschrieben und soll libbatterymonitor und libhealthd. BOARD . Diese Benutzer von health@2.0-impl dürfen BatteryMonitor oder die Funktionen in libhealthd nicht direkt verwenden; Stattdessen sollten diese Aufrufe durch Aufrufe in die Health Klasse ersetzt werden, eine Implementierung der IHealth Schnittstelle. Um es weiter zu verallgemeinern: Der Code healthd_common ist auch in „health@2.0-impl“ enthalten. Das neue healthd_common enthält den Rest des gemeinsamen Codes zwischen „health@2.0-service“, „charger“ und „ healthd “ und ruft IHealth-Methoden anstelle von BatteryMonitor auf.

Implementierung des Health 2.0-Dienstes

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

  • Für das Gerät ausreichend, verwenden Sie direkt android.hardware.health@2.0-service .

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

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

Dann:

  • Wenn Board-spezifische libhealthd:

    • Existiert, Link dazu.
    • Existiert nicht. Stellen Sie leere Implementierungen für die Funktionen healthd_board_init “ und healthd_board_battery_update bereit.

  • Wenn platinenspezifische BOARD_PERIODIC_CHORES_INTERVAL_* Variablen:

    • Sind definiert, erstellen Sie eine gerätespezifische HealthServiceCommon.cpp (kopiert von hardware/interfaces/health/2.0/utils/libhealthservice ) und passen Sie sie in healthd_mode_service_2_0_init an.
    • Sind nicht definiert, verknüpfen Sie statisch mit libhealthservice .

  • Wenn Gerät:

    • Sollten die APIs getStorageInfo und getDiskStats implementiert werden, stellen Sie die Implementierung in den Funktionen get_storage_info und get_disk_stats bereit.
    • Sollten diese APIs nicht implementiert werden, verlinken Sie statisch auf libstoragehealthdefault .

  • Aktualisieren Sie die erforderlichen SELinux-Berechtigungen.

  • Implementieren Sie HAL in der Wiederherstellung, indem Sie eine Passthrough-Implementierung im 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>

Einzelheiten finden Sie unter hardware/interfaces/health/2.0/README.md .

Gesundheitskunden

Siehe Gesundheitsclients für Gesundheit 2.1 HAL .

SELinux-Änderungen

Das neue health@2.0 HAL beinhaltet die folgenden SELinux-Änderungen:

  • Fügt „health@2.0-service“ zu file_contexts hinzu.
  • Ermöglicht system_server und storaged die Verwendung von hal_health .
  • Ermöglicht system_server ( BatteryService ), batteryproperties_service ( IBatteryPropertiesRegistrar ) zu registrieren.
  • Ermöglicht healthd , hal_health bereitzustellen.
  • Entfernt Regeln, die es system_server / storaged ermöglichen, über einen Binder in healthd einzudringen.
  • Entfernt Regeln, die es healthd ermöglichen, batteryproperties_service ( IBatteryPropertiesRegistrar ) zu registrieren.

Für Geräte mit eigener Implementierung können einige SELinux-Änderungen des Anbieters 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 Health 2.1 HAL .

Testen

Android 9 enthält neue VTS-Tests, die speziell für den Health@2.0-HAL geschrieben wurden. Wenn ein Gerät im Gerätemanifest angibt, „health@2.0“-HAL bereitzustellen, muss es die entsprechenden VTS-Tests bestehen. Tests werden sowohl für die Standardinstanz (um sicherzustellen, dass das Gerät die HAL korrekt implementiert) als auch für die Backup-Instanz geschrieben (um sicherzustellen, dass healthd weiterhin ordnungsgemäß funktioniert, bevor es entfernt wird).

Anforderungen an Batterieinformationen

Siehe Anforderungen an Batterieinformationen .