Gesundheit 2.0 umsetzen

Der gesamte healthd -Code wurde in health@2.0-impl und libhealthservice umgestaltet und dann modifiziert, um health@2.0 HAL zu implementieren. Diese beiden Bibliotheken werden statisch von health@2.0-service gelinkt, was es ihm ermöglicht, die Arbeit zu erledigen, die zuvor von healthd erledigt wurde (dh healthd_mainloop und Polling durchführen). In init registriert der health@2.0-Dienst 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 den Ablaufplan erzwungen.

So beheben Sie dieses Problem:

  1. healthd registriert IHealth bei hwservicemanager (obwohl es sich um einen Systemdämon handelt). IHealth wird dem Systemmanifest mit dem Instanznamen „backup“ hinzugefügt.
  2. Framework und storaged kommunizieren mit healthd über hwbinder anstelle von binder .
  3. Code für Framework und storaged werden geändert, um die Instanz "default" abzurufen, falls verfügbar, dann "backup".
    • C++-Clientcode verwendet die in libhealthhalutils definierte Logik.
    • Java-Clientcode verwendet die in HealthServiceWrapper definierte Logik.
  4. Nachdem IHealth/default allgemein verfügbar ist und Android 8.1-Herstellerimages veraltet sind, können IHealth/backup und healthd veraltet sein. Weitere Einzelheiten finden Sie unter Verwerfen von health@1.0 .

Boardspezifische Build-Variablen für healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sind Board-spezifische Variablen, die zum Erstellen von healthd verwendet werden. Als Teil der Build-Aufteilung zwischen System und Anbieter 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 (indem sie libhealthservice Abhängigkeit in health@2.0-service.<device> und diese Funktion neu implementieren).

Statische Implementierungsbibliothek

Im Gegensatz zu anderen HAL-Implementierungsbibliotheken ist die Implementierungsbibliothek „health@2.0-impl“ eine statische Bibliothek, mit der „health@2.0-service“, „charger“, „recovery“ und „legacy-healthd“ verknüpft sind.

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 der Health -Klasse, einer Implementierung der IHealth Schnittstelle, ersetzt werden. Zur weiteren Verallgemeinerung ist der Code healthd_common 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.

Implementieren des Health 2.0-Dienstes

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

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

  • Für das Gerät nicht ausreichend, 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(); }

Dann:

  • Wenn Board-spezifischer libhealthd:

    • Existiert, Link dazu.
    • Nicht vorhanden, stellen Sie leere Implementierungen für die Funktionen healthd_board_init und healthd_board_battery_update .

  • Wenn Board-spezifische BOARD_PERIODIC_CHORES_INTERVAL_* Variablen:

    • definiert sind, erstellen Sie eine gerätespezifische HealthServiceCommon.cpp (kopiert aus hardware/interfaces/health/2.0/utils/libhealthservice ) und passen Sie diese in healthd_mode_service_2_0_init an.
    • Sind nicht definiert, statisch auf libhealthservice .

  • Wenn Gerät:

    • Sollten getStorageInfo und getDiskStats APIs implementiert werden, stellen Sie die Implementierung in den Funktionen get_storage_info und get_disk_stats .
    • 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 für das Wiederherstellungsabbild 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 Health-Clients für Gesundheit 2.1 HAL .

SELinux-Änderungen

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

  • Fügt den health@2.0-Dienst zu file_contexts .
  • Ermöglicht system_server und storaged die Verwendung von hal_health .
  • Ermöglicht system_server ( BatteryService ) die Registrierung von batteryproperties_service ( IBatteryPropertiesRegistrar ).
  • Ermöglicht healthd die Bereitstellung von hal_health .
  • Entfernt Regeln, die es system_server / storaged ermöglichen, healthd über Binder aufzurufen.
  • Entfernt Regeln, die es healthd erlauben, batteryproperties_service ( IBatteryPropertiesRegistrar ) zu registrieren.

Für Geräte 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.

Kernel-Schnittstellen

Siehe Kernel-Schnittstellen für Health 2.1 HAL .

Testen

Android 9 enthält neue VTS-Tests , die speziell für die HAL health@2.0 geschrieben wurden. Wenn ein Gerät im Gerätemanifest erklärt, 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 Sicherungsinstanz (um sicherzustellen, dass healthd weiterhin ordnungsgemäß funktioniert, bevor es entfernt wird) geschrieben.

Anforderungen an Batterieinformationen

Siehe Anforderungen an Batterieinformationen .