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:
-
healthd
registriertIHealth
beihwservicemanager
(obwohl es sich um einen Systemdämon handelt).IHealth
wird dem Systemmanifest mit dem Instanznamen „backup“ hinzugefügt. - Framework und
storaged
kommunizieren mithealthd
überhwbinder
anstelle vonbinder
. - 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.
- C++-Clientcode verwendet die in
- 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
undhealthd_board_battery_update
.
Wenn Board-spezifische
BOARD_PERIODIC_CHORES_INTERVAL_*
Variablen:- definiert sind, erstellen Sie eine gerätespezifische
HealthServiceCommon.cpp
(kopiert aushardware/interfaces/health/2.0/utils/libhealthservice
) und passen Sie diese inhealthd_mode_service_2_0_init
an. - Sind nicht definiert, statisch auf
libhealthservice
.
- definiert sind, erstellen Sie eine gerätespezifische
Wenn Gerät:
- Sollten
getStorageInfo
undgetDiskStats
APIs implementiert werden, stellen Sie die Implementierung in den Funktionenget_storage_info
undget_disk_stats
. - Sollten diese APIs nicht implementiert werden, verlinken Sie statisch auf
libstoragehealthdefault
.
- Sollten
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
undstoraged
die Verwendung vonhal_health
. - Ermöglicht
system_server
(BatteryService
) die Registrierung vonbatteryproperties_service
(IBatteryPropertiesRegistrar
). - Ermöglicht
healthd
die Bereitstellung vonhal_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 .