Android 9 enthält android.hardware.health
HAL 2.0, ein Hauptversions-Upgrade von health@1.0 HAL. Diese neue HAL hat folgende Vorteile:
- Sauberere Trennung zwischen Framework und Herstellercode.
- Verwirft den unnötigen
healthd
Daemon. - Größere Freiheitsgrade für die Anbieteranpassung in Gesundheitsinformationsberichten.
- Mehr Informationen zum Gerätezustand als nur zum Akku.
Android 11 enthält android.hardware.health
HAL 2.1, ein Nebenversions-Upgrade von health@2.0 HAL. Diese neue HAL hat folgende Vorteile:
- Einfacher umzusetzen
- Bessere Konformität mit bestehenden 2.0-HAL-APIs
- Bessere Höhentrennung im Ladecode im Aus-Modus
- Bessere Unterstützung für das Framework, um den Batteriezustand des Geräts anzuzeigen
Android 13 enthält android.hardware.health
AIDL HAL, eine Konvertierung von health@2.1 HAL. Diese neue HAL hat folgende Vorteile:
- Entfernen Sie ungenutzte ladegerätbezogene APIs
- Entfernen Sie unbenutzte
StorageAttribute
und verwandte Felder - Dock-Aufladung unterstützen.
Anforderungen
Geräte mit Android 9 und Android 10
Geräte, die mit Android 9 gestartet werden, müssen die 2.x-HAL (und dürfen die 1.0-HAL nicht bereitstellen) oder die AIDL-HAL bereitstellen. Geräte, die nicht mit Android 9 starten, aber planen, das Anbieter-Image auf Target Framework Compatibility Matrix Version 3 (veröffentlicht in Android 9) zu aktualisieren, müssen vorhandene 1.0-HAL-Implementierungen entfernen und die 2.x-HAL oder die AIDL-HAL bereitstellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung der HAL 2.0 und beim Übergang von der alten HAL 1.0 helfen sollen.
Geräte mit Android 11 und Android 12
Geräte, die mit Android 11 gestartet werden, müssen die 2.1 HAL (und dürfen die 1.0 oder 2.0 HAL nicht bereitstellen) oder die AIDL HAL bereitstellen. Geräte, die nicht mit Android 11 starten, aber planen, das Anbieter-Image auf Target Framework Compatibility Matrix Version 5 (veröffentlicht in Android 11) zu aktualisieren, müssen vorhandene 2.0-HAL-Implementierungen entfernen und die 2.1-HAL oder die AIDL-HAL bereitstellen. Für Geräte, die nicht mit Android 11 starten und nicht planen, das Anbieter-Image zu aktualisieren, wird ebenfalls empfohlen, die 2.1 HAL bereitzustellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung der 2.1-HAL und dem Übergang von der alten 1.0-HAL helfen sollen.
Geräte mit Android 13 und höher
Geräte, die mit Android 13 gestartet werden, müssen AIDL HAL bereitstellen (und dürfen HIDL HAL nicht bereitstellen). Geräte, die nicht mit Android 13 starten, aber planen, das Anbieter-Image auf Target Framework Compatibility Matrix Version 7 (veröffentlicht in Android 13) zu aktualisieren, müssen vorhandene HIDL-HAL-Implementierungen entfernen und die AIDL-HAL bereitstellen. Für Geräte, die nicht mit Android 13 starten und nicht planen, das Anbieter-Image zu aktualisieren, wird ebenfalls empfohlen, die AIDL HAL bereitzustellen.
Geräte dürfen die HIDL 1.0 HAL nicht bereitstellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen beim Implementieren der AIDL-HAL und beim Übergang von den alten HIDL-HALs helfen sollen.
Terminologie
- health@1.0 : Abkürzung für
android.hardware.health@1.0
. Bezieht sich auf Health HIDL HAL Version 1.0, die in Android 8.0 veröffentlicht wurde. - health@2.0 : Abkürzung für
android.hardware.health@2.0
. Bezieht sich auf Health HIDL HAL Version 2.0, die in Android 9 veröffentlicht wurde. - health@2.1 : Abkürzung für
android.hardware.health@2.1
. Bezieht sich auf Health HIDL HAL Version 2.1, die in Android 11 veröffentlicht wurde. - Gesundheit AIDL HAL : Abkürzung für
android.hardware.health
.- Version 1 wird in Android 13 veröffentlicht.
- Charger : Ausführbare Datei, die im Off-Modus läuft und die Animation zum Aufladen des Telefons anzeigt.
- recovery : ausführbare Datei, die im Wiederherstellungsmodus ausgeführt wird und Batterieinformationen abrufen muss.
- healthd : Legacy-Daemon, der in Android ausgeführt wird und gesundheitsbezogene Informationen abruft und sie dem Framework bereitstellt.
- storaged : In Android ausgeführter Daemon, der Speicherinformationen abruft und sie dem Framework bereitstellt.
Gesundheit in Android 8.x
In Android 8.x funktioniert die Health-Komponente wie im folgenden Diagramm beschrieben:
Abbildung 1 . Gesundheit in Android 8.x
In diesem Diagramm:
- Ein (1) binder-Aufruf und ein (1) hwbinder-Aufruf werden vom Framework verwendet, um mit der Hardware zu kommunizieren.
-
healthd
verlinkt statisch auflibhealthd_android
,libbatterymonitor
undlibbatteryservice
. - health@1.0-impl verlinkt statisch auf
libhealthd. BOARD
.
Jedes Board kann eine andere libhealthd. BOARD
; es wird zum Build-Zeitpunkt festgelegt, womit Charger, health@1.0-impl und recovery verknüpft sind.
Für andere Modi:
Abbildung 2. Zustand in Android 8.x, Lade- und Wiederherstellungsmodus im Aus-Modus
- Charger verlinkt statisch auf
libhealthd. BOARD
,libhealthd_charger
undlibbatterymonitor
. - recovery verlinkt statisch auf
libhealthd. BOARD
undlibbatterymonitor
.
Gesundheit in Android 9
In Android 9 funktioniert die Health-Komponente wie im folgenden Diagramm beschrieben:
Abbildung 3 . Gesundheit in Android 9
Das Framework versucht, den health@2.0-Dienst von hwservicemanager
. Wenn es fehlschlägt, ruft es health@1.0 (in Android 8.x) auf. Der alte Codepfad wird beibehalten, damit das Android 9-Systemabbild mit dem Android 8.x-Herstellerabbild kompatibel ist. Das Framework ruft keine Informationen von beiden HALs ab, da auf dem Gerät nur eine Dienstversion (1.0 oder 2.0) vorhanden sein kann.
Für andere Modi:
Abbildung 4. Gesundheit in Android 9, Lade- und Wiederherstellungsmodus im Aus-Modus
Gesundheit in Android 11
In Android 11 funktioniert die Gesundheitskomponente wie im folgenden Diagramm beschrieben:
[system]
| getService()
V
[health@2.1-service]
| getService(stub=true)
V
[ health@2.0-impl-2.1-<device>.so ]
| | (device-dependent linkage)
V V
+---------Helper libs for impl--------+ [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl) ] |
| [libbatterymonitor (battery) ] |
+-------------------------------------+
Wenn die Health 2.1-Implementierung nicht vorhanden ist, greift das System auf den Legacy-Codepfad zurück, wie in den vorherigen Abschnitten beschrieben
Für andere Modi:
[ charger ]
| getService() | (legacy code path)
V +-------------------------------------------------+
[health@2.1-service] |
| getService(stub=true) |
V |
[ health@2.0-impl-2.1-<device>.so ] |
| | (device-dependent linkage) |
V V |
+---------Helper libs for impl--------+ [libhealthd.device] |
| [libhealthloop (uevent, wakealarm)] | |
| [libhealth2impl (IHealth impl) ] | <---------------------------------+
| [libbatterymonitor (battery) ] |
+-------------------------------------+
[recovery]
| getService() w/o hwservicemanager
V
[ health@2.0-impl-2.1-<device>.so ]
| | (device-dependent linkage)
V V
+---------Helper libs for impl--------+ [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl) ] |
| [libbatterymonitor (battery) ] |
+-------------------------------------+
Siehe das folgende vereinfachte Diagramm für verschiedene Modi:
Abbildung 5. Health HAL 2.1-Infrastruktur
Gesundheit in Android 13
In Android 13 wird die Gesundheits-AIDL HAL eingeführt. Die Gesundheitskomponente funktioniert wie im folgenden Diagramm beschrieben:
Abbildung 6. Health AIDL HAL-Infrastruktur
HIDL HAL-Schnittstelle 2.0
Die HAL health@2.0 bietet dem Framework die gleiche Funktionalität wie der alte Daemon healthd. Es bietet auch APIs, die denen ähneln, die healthd zuvor als Bindedienst bereitgestellt hat (z. B. IBatteryPropertiesRegistrar ).
Die Hauptschnittstelle, IHealth , bietet die folgenden Funktionen:
-
registerCallback
, umIBatteryPropertiesRegistrar.registerListener
zu ersetzen -
unregisterCallback
, umIBatteryPropertiesRegistrar.unregisterListener
zu ersetzen -
update
, umIBatteryPropertiesRegistrar.scheduleUpdate
zu ersetzen -
IBatteryPropertiesRegistrar.getProperties
werden durch Folgendes ersetzt:-
getChargeCounter
-
getCurrentNow
-
getCurrentAverage
-
getCapacity
-
getEnergyCounter
-
getChargeStatus
-
getHealthInfo
-
Darüber hinaus stellt IHealth
die folgenden neuen APIs für storaged
, um anbieterspezifische speicherbezogene Informationen abzurufen:
-
getStorageInfo
-
getDiskStats
Eine neue Struktur, @2.0::HealthInfo
, wird über Callbacks und getHealthInfo
. Diese Struktur enthält alle Informationen zum Gerätezustand, die über health@2.0 HAL verfügbar sind, einschließlich:
- Ladeinformationen (AC/USB/Wireless, Strom, Spannung usw.)
- Batterieinformationen (Anwesenheit, Batteriestand, Strom, Spannung, Ladung, Technologie usw.)
- Speicherinformationen (Informationen zu Speichergeräten, Festplattenstatistiken)
Informationen zum Implementieren des Health-Dienstes 2.0 finden Sie unter Implementieren von Health 2.0 .
HIDL HAL-Schnittstelle 2.1
Der health@2.1 HAL unterstützt das Laden im Aus-Modus und bietet mehr Informationen über den Akku.
Die Hauptschnittstelle, IHealth , bietet die folgenden zusätzlichen Funktionen
-
getHealthConfig
: zum Abrufen der Konfiguration dieser HAL -
getHealthInfo_2_1
: ein Nebenversions-Upgrade aufgetHealthInfo
-
shouldKeepScreenOn
: um festzulegen, ob der Bildschirm im Lademodus eingeschaltet bleiben soll
Darüber hinaus ist die Implementierung von @2.1::IHealth
erforderlich, um @2.1::IHealthInfoCallback
für seine geerbten registerCallback
und unregisterCallback
-Funktionen zu unterstützen. Die neue Callback-Schnittstelle gibt Zustandszustandsinformationen an den Client zurück, indem sie ihre Funktion healthInfoChanged_2_1
anstelle der geerbten Funktion healthInfoChanged
verwendet.
Eine neue Struktur, @2.1::HealthInfo
, wird über Callbacks und getHealthInfo_2_1
. Diese Struktur enthält zusätzliche Informationen zum Gerätezustand, die über health@2.0 HAL verfügbar sind, einschließlich:
- Batteriekapazität
- Ladezeit des Akkus jetzt vollständig (in Sekunden)
- Auslegungskapazität der Batterie bei voller Ladung (in μAh)
Siehe das folgende UML-Diagramm für die Klassen, die für die Health-HAL-Implementierung nützlich sind:
Abbildung 7. Health HAL 2.1 UML-Diagramm
Informationen zum Implementieren von Health Service 2.1 finden Sie unter Implementieren von Health 2.1 .
AIDL HAL-Schnittstellenversion 1
API-Änderungen
Die AIDL Version 1 HAL unterstützt ähnliche APIs wie die HIDL 2.1 HAL. Im Vergleich zur HIDL 2.1-Schnittstelle wurde in der API Folgendes geändert:
- Auf Ladegeräte bezogene APIs, die in HIDL HAL 2.1 eingeführt wurden, werden nicht auf AIDL HAL portiert. Da die Funktionalität des Off-Mode-Charging nur auf der
/vendor
-Partition vorhanden ist, sind APIs auf der Vendor-Schnittstelle nicht erforderlich. Um das Aufladen im Aus-Modus richtig zu implementieren, siehe Ladegerät unten. - Type
StorageAttribute
und verwandte Felder werden entfernt, da sie nicht verwendet werden. -
chargerDockOnline
wirdHealthInfo
hinzugefügt, um das Aufladen des Docks zu unterstützen.
Implementierung
Siehe das folgende UML-Diagramm für die Klassen, die für die Health-HAL-Implementierung nützlich sind:
Abbildung 8. Health AIDL HAL UML-Diagramm
Informationen zur Implementierung des Health-AIDL-Dienstes finden Sie unter Implementing Health AIDL HAL .
Wiederherstellung
Android 13 unterstützt Binder bei der Wiederherstellung. Durch die Installation des Health AIDL-Dienstes zur Wiederherstellung kann dieser im Wiederherstellungsmodus ausgeführt werden.
Informationen zum Installieren des Integritäts-AIDL-Diensts für die Wiederherstellung finden Sie hier:
Ladegerät
Die Funktionalität des Ladens im Aus-Modus wurde von /system
nach /vendor
verschoben. Für Geräte, die mit Android 13 gestartet werden, muss die HAL-Dienstbinärdatei den Lademodus unterstützen, wenn sie das Laden im Aus-Modus unterstützen. Siehe hierzu Implementierung des Ladegeräts .
Eigenschaften des Ladesystems
Die Eigenschaften ro.charger.*
sind von der charger
-Binärdatei in /vendor
nicht mehr lesbar. Wenn für Ihr Gerät eine der ro.charger.*
-Systemeigenschaften festgelegt ist, lesen Sie die Systemeigenschaften für das Ladegerät .