In Android 11 wird der gesamte healthd
Code in libhealthloop
und libhealth2impl
umgestaltet und dann geändert, um die HAL von health@2.1 zu implementieren. Diese beiden Bibliotheken sind statisch durch health@2.0-impl-2.1
verknüpft, die Passthrough-Implementierung von Health 2.1. Die statisch verknüpften Bibliotheken ermöglichen es health@2.0-impl-2.1
die gleichen Aufgaben wie healthd
auszuführen, z. B. das Ausführen healthd_mainloop
und das Abfragen. In init registriert der health@2.1-service
eine Implementierung der Schnittstelle IHealth
zu hwservicemanager
. Beim Upgrade von Geräten mit einem Android 8.x- oder 9-Anbieter-Image und einem Android 11-Framework stellt das Anbieter-Image möglicherweise nicht den Dienst „health@2.1“ bereit. Die Abwärtskompatibilität mit alten Anbieter-Images wird durch den Einstellungsplan erzwungen.
Um die Abwärtskompatibilität sicherzustellen:
-
healthd
registriertIHealth
beihwservicemanager
, obwohl es sich um einen Systemdämon handelt.IHealth
wird dem Systemmanifest mit dem Instanznamen „backup“ hinzugefügt. - Das Framework und
storaged
kommunizieren mithealthd
überhwbinder
statt überbinder
. - Der Code für Framework und
storaged
wird geändert, um die Instanz „default“, falls verfügbar, und dann „backup“ abzurufen.- C++-Clientcode verwendet die in
libhealthhalutils
definierte Logik. - Der Java-Clientcode verwendet die in
HealthServiceWrapper
definierte Logik.
- C++-Clientcode verwendet die in
- 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. Diese Werte wurden früher in der veralteten Funktion healthd_board_init
überschrieben.
In health@2.1 können Anbieter diese beiden Intervallwerte für periodische Aufgaben in der Struktur healthd_config
überschreiben, bevor sie an den Konstruktor der Gesundheitsimplementierungsklasse übergeben werden. Die Gesundheitsimplementierungsklasse sollte von android::hardware::health::V2_1::implementation::Health
erben.
Implementieren Sie den Health 2.1-Dienst
Informationen zur Implementierung des Health 2.1-Dienstes finden Sie unter hardware/interfaces/health/2.1/README.md .
Gesundheitskunden
health@2.x hat folgende Kunden:
- Ladegerät. Die Verwendung von
libbatterymonitor
healthd_common
-Code isthealth@2.0-impl
eingeschlossen. - Erholung. Die Verknüpfung zu
libbatterymonitor
ist inhealth@2.0-impl
verpackt. Alle Aufrufe vonBatteryMonitor
werden durch Aufrufe in derHealth
Implementierungsklasse ersetzt. BatterieManager.
BatteryManager.queryProperty(int id)
war der einzige Client vonIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
wurde vonhealthd
bereitgestellt und/sys/class/power_supply
direkt gelesen.Aus Sicherheitsgründen ist es Apps nicht gestattet, Health HAL direkt aufzurufen. In Android 9 und höher wird der Binderdienst
IBatteryPropertiesRegistrar
vonBatteryService
anstelle vonhealthd
bereitgestellt.BatteryService
delegiert den Aufruf an die Gesundheits-HAL, um die angeforderten Informationen abzurufen.BatterieService. In Android 9 und höher verwendet
BatteryService
HealthServiceWrapper
, um zu bestimmen, ob die Standardinstanz des Gesundheitsdiensts vomvendor
oder die Backup- Instanz des Gesundheitsdiensts vonhealthd
verwendet werden soll.BatteryService
wartet dann überIHealth.registerCallback
auf Gesundheitsereignisse.Gespeichert. In Android 9 und höher verwendet
storaged
libhealthhalutils
um zu bestimmen, ob die Standardinstanz des Integritätsdiensts vomvendor
oder die Backup- Instanz des Integritätsdiensts vonhealthd
verwendet werden soll.storaged
lauscht dann überIHealth.registerCallback
auf Gesundheitsereignisse und ruft Speicherinformationen ab.
SELinux-Änderungen
Das Health@2.1 HAL beinhaltet die folgenden SELinux-Änderungen in der Plattform:
- Fügt
android.hardware.health@2.1-service
zufile_contexts
hinzu.
Für Geräte mit eigener Implementierung können einige SELinux-Änderungen des Anbieters erforderlich sein. Beispiel:
# 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
Der healthd
Daemon und die Standardimplementierung android.hardware.health@2.0-impl-2.1
greifen auf die folgenden Kernel-Schnittstellen zu, um Batterieinformationen abzurufen:
-
/sys/class/power_supply/*/capacity_level
(hinzugefügt in Health 2.1) -
/sys/class/power_supply/*/capacity
-
/sys/class/power_supply/*/charge_counter
-
/sys/class/power_supply/*/charge_full
-
/sys/class/power_supply/*/charge_full_design
(hinzugefügt in Health 2.1) -
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
-
/sys/class/power_supply/*/cycle_count
-
/sys/class/power_supply/*/health
-
/sys/class/power_supply/*/online
-
/sys/class/power_supply/*/present
-
/sys/class/power_supply/*/status
-
/sys/class/power_supply/*/technology
-
/sys/class/power_supply/*/temp
-
/sys/class/power_supply/*/time_to_full_now
(hinzugefügt in Health 2.1) -
/sys/class/power_supply/*/type
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
Jede gerätespezifische Health-HAL-Implementierung, die libbatterymonitor
verwendet, greift standardmäßig auf diese Kernel-Schnittstellen zu, sofern sie nicht im Konstruktor der Health-Implementierungsklasse überschrieben wird.
Wenn diese Dateien fehlen oder über healthd
oder den Standarddienst nicht zugänglich sind (z. B. handelt es sich bei der Datei um einen symbolischen Link zu einem herstellerspezifischen Ordner, der den Zugriff aufgrund einer falsch konfigurierten SELinux-Richtlinie verweigert), funktionieren sie möglicherweise nicht ordnungsgemäß. Daher können zusätzliche herstellerspezifische SELinux-Änderungen erforderlich sein, auch wenn die Standardimplementierung verwendet wird.
Einige in Health 2.1 verwendete Kernel-Schnittstellen, wie z. B. /sys/class/power_supply/*/capacity_level
und /sys/class/power_supply/*/time_to_full_now
, sind möglicherweise optional. Um jedoch falsches Framework-Verhalten aufgrund fehlender Kernel-Schnittstellen zu verhindern, wird empfohlen, CL 1398913 auszuwählen, bevor der Health HAL 2.1-Dienst erstellt wird.
Testen
Android 11 enthält neue VTS-Tests , die speziell für das HAL „health@2.1“ geschrieben wurden. Wenn ein Gerät im Gerätemanifest „health@2.1 HAL“ deklariert, 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
Das Health 2.0 HAL legt eine Reihe von Anforderungen an die HAL-Schnittstelle fest, die entsprechenden VTS-Tests gehen jedoch bei der Durchsetzung dieser Anforderungen relativ locker vor. In Android 11 werden neue VTS-Tests hinzugefügt, um die folgenden Anforderungen auf Geräten zu erzwingen, die mit Android 11 und höher gestartet werden:
- Die Einheiten des momentanen und durchschnittlichen Batteriestroms müssen Mikroampere (μA) sein.
- Das Vorzeichen des momentanen und durchschnittlichen Batteriestroms muss korrekt sein. Speziell:
- Strom == 0, wenn der Batteriestatus
UNKNOWN
ist - Strom > 0, wenn der Batteriestatus
CHARGING
lautet - Strom <= 0, wenn der Batteriestatus
NOT_CHARGING
ist - Strom < 0, wenn der Batteriestatus
DISCHARGING
ist - Wird nicht erzwungen, wenn der Batteriestatus
FULL
ist
- Strom == 0, wenn der Batteriestatus
- Der Batteriestatus muss unabhängig davon, ob eine Stromquelle angeschlossen ist oder nicht, korrekt sein. Speziell:
- Der Batteriestatus muss nur dann
CHARGING
,NOT_CHARGING
oderFULL
sein, wenn eine Stromquelle angeschlossen ist. - Der Batteriestatus muss nur dann
DISCHARGING
, wenn eine Stromquelle getrennt ist.
- Der Batteriestatus muss nur dann
Wenn Sie libbatterymonitor
in Ihrer Implementierung verwenden und Werte von Kernel-Schnittstellen weiterleiten, stellen Sie sicher, dass die sysfs-Knoten korrekte Werte melden:
- Stellen Sie sicher, dass der Batteriestrom mit dem richtigen Vorzeichen und den richtigen Einheiten angegeben wird. Dazu gehören die folgenden sysfs-Knoten:
-
/sys/class/power_supply/*/current_avg
-
/sys/class/power_supply/*/current_max
-
/sys/class/power_supply/*/current_now
- Positive Werte zeigen an, dass Strom in die Batterie fließt.
- Die Werte sollten in Mikroampere (μA) angegeben werden.
-
- Stellen Sie sicher, dass die Batteriespannung in Mikrovolt (μV) angegeben wird. Dazu gehören die folgenden sysfs-Knoten:
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
- Beachten Sie, dass die Standard-HAL-Implementierung „
voltage_now
durch 1000 dividiert und Werte in Millivolt (mV) meldet. Siehe @1.0::HealthInfo .
-
Einzelheiten finden Sie unter Linux-Netzteilklasse .