Android 9 enthält android.hardware.health
HAL 2.0, ein Hauptversions-Upgrade von health@1.0 HAL. Dieser neue HAL bietet folgende Vorteile:
- Sauberere Trennung zwischen Framework und Anbietercode.
- Veraltet den unnötigen
healthd
Daemon. - Größere Freiheitsgrade bei der 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. Dieser neue HAL bietet folgende Vorteile:
- Einfacher umzusetzen
- Bessere Konformität mit bestehenden 2.0 HAL APIs
- Bessere Höhentrennung im Aus-Modus-Ladecode
- Bessere Unterstützung für das Framework zur Anzeige des Batteriezustands des Geräts
Android 13 enthält android.hardware.health
AIDL HAL, eine Konvertierung von health@2.1 HAL. Dieser neue HAL bietet folgende Vorteile:
- Entfernen Sie nicht verwendete ladegerätbezogene APIs
- Entfernen Sie nicht verwendetes
StorageAttribute
und zugehörige Felder - Unterstützt das Aufladen über die Dockingstation.
Anforderungen
Geräte mit Android 9 und Android 10
Geräte, die mit Android 9 gestartet werden, müssen den 2.x-HAL (und dürfen den 1.0-HAL nicht bereitstellen) oder den AIDL-HAL bereitstellen. Geräte, die nicht mit Android 9 gestartet werden, aber planen, das Hersteller-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 des 2.0 HAL und beim Übergang vom alten 1.0 HAL helfen sollen.
Geräte mit Android 11 und Android 12
Geräte, die mit Android 11 gestartet werden, müssen den 2.1 HAL (und dürfen nicht den 1.0 oder 2.0 HAL bereitstellen) oder den AIDL HAL bereitstellen. Geräte, die nicht mit Android 11 gestartet werden, aber planen, das Hersteller-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 gestartet werden und keine Aktualisierung des Anbieter-Images planen, wird ebenfalls empfohlen, den 2.1 HAL bereitzustellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung des 2.1 HAL und beim Übergang vom 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 Hersteller-Image auf Target Framework Compatibility Matrix Version 7 (veröffentlicht in Android 13) zu aktualisieren, müssen vorhandene HIDL HAL-Implementierungen entfernen und AIDL HAL bereitstellen. Für Geräte, die nicht mit Android 13 gestartet werden und keine Aktualisierung des Anbieter-Images planen, wird ebenfalls empfohlen, den AIDL HAL bereitzustellen.
Geräte dürfen HIDL 1.0 HAL nicht bereitstellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung des 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, veröffentlicht in Android 8.0. - health@2.0 : Abkürzung für
android.hardware.health@2.0
. Bezieht sich auf die in Android 9 veröffentlichte Health HIDL HAL Version 2.0. - health@2.1 : Abkürzung für
android.hardware.health@2.1
. Bezieht sich auf die in Android 11 veröffentlichte Health HIDL HAL Version 2.1. - Gesundheit AIDL HAL : Abkürzung für
android.hardware.health
.- Version 1 wird in Android 13 veröffentlicht.
- Ladegerät : Ausführbare Datei, die im ausgeschalteten Lademodus ausgeführt wird und die Animation zum Aufladen des Telefons anzeigt.
- Wiederherstellung : 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 diese dem Framework bereitstellt.
- storaged : In Android ausgeführter Daemon, der Speicherinformationen abruft und dem Framework bereitstellt.
Gesundheit in Android 8.x
In Android 8.x funktioniert die Gesundheitskomponente 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 zur Kommunikation mit der Hardware verwendet.
-
healthd
ist statisch mitlibhealthd_android
,libbatterymonitor
undlibbatteryservice
verknüpft. - health@1.0-impl verknüpft statisch mit
libhealthd. BOARD
.
Jedes Board kann eine andere libhealthd. BOARD
; Es wird zum Zeitpunkt der Erstellung festgelegt, zu welchem Ladegerät, Health@1.0-impl und Wiederherstellung eine Verknüpfung besteht.
Für andere Modi:
Abbildung 2. Zustand in Android 8.x, Lade- und Wiederherstellungsmodus im ausgeschalteten Zustand
- Das Ladegerät ist statisch mit
libhealthd. BOARD
,libhealthd_charger
undlibbatterymonitor
. - Die Wiederherstellung ist statisch mit
libhealthd. BOARD
undlibbatterymonitor
.
Gesundheit in Android 9
In Android 9 funktioniert die Gesundheitskomponente wie im folgenden Diagramm beschrieben:
Figur 3 . Gesundheit in Android 9
Das Framework versucht, den Health@2.0-Dienst von hwservicemanager
abzurufen. Wenn dies fehlschlägt, wird „health@1.0“ (in Android 8.x) aufgerufen. Der Legacy-Codepfad wird beibehalten, sodass das Android 9-System-Image mit dem Android 8.x-Anbieter-Image 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 ausgeschalteten Zustand
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) ] |
+-------------------------------------+
Die verschiedenen Modi finden Sie im folgenden vereinfachten Diagramm:
Abbildung 5. Health HAL 2.1-Infrastruktur
Gesundheit in Android 13
In Android 13 wird das Gesundheits-AIDL HAL eingeführt. Die Gesundheitskomponente funktioniert wie im folgenden Diagramm beschrieben:
Abbildung 6. Health AIDL HAL-Infrastruktur
HIDL HAL-Schnittstelle 2.0
Der Health@2.0-HAL bietet dem Framework die gleiche Funktionalität wie der alte Healthd-Daemon. Es stellt außerdem APIs bereit, die denen ähneln, die Healthd zuvor als Binder-Dienst 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
bereit, um herstellerspezifische speicherbezogene Informationen abzurufen:
-
getStorageInfo
-
getDiskStats
Eine neue Struktur, @2.0::HealthInfo
, wird über Rückrufe und getHealthInfo
zurückgegeben. Diese Struktur enthält alle über health@2.0 HAL verfügbaren Informationen zum Gerätezustand, einschließlich:
- Ladeinformationen (AC/USB/kabellos, Strom, Spannung usw.)
- Batterieinformationen (Anwesenheit, Batteriestand, Strom, Spannung, Ladung, Technologie usw.)
- Speicherinformationen (Informationen zum Speichergerät, Festplattenstatistiken)
Informationen zur Implementierung des Health Service 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 Off-Modus und liefert weitere Informationen über den Akku.
Die Hauptschnittstelle IHealth bietet die folgenden zusätzlichen Funktionen
-
getHealthConfig
: um die Konfiguration dieser HAL abzurufen -
getHealthInfo_2_1
: ein Nebenversions-Upgrade aufgetHealthInfo
-
shouldKeepScreenOn
: um zu bestimmen, 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 Funktionen registerCallback
und unregisterCallback
zu unterstützen. Die neue Rückrufschnittstelle gibt Gesundheitsinformationen mithilfe ihrer Funktion healthInfoChanged_2_1
“ anstelle der geerbten Funktion „ healthInfoChanged
an den Client zurück.
Eine neue Struktur, @2.1::HealthInfo
, wird über Rückrufe und getHealthInfo_2_1
zurückgegeben. Diese Struktur enthält zusätzliche Informationen zum Gerätezustand, die über health@2.0 HAL verfügbar sind, darunter:
- Batteriekapazitätsniveau
- Jetzt dauert es, bis der Akku vollständig aufgeladen ist (in Sekunden)
- Auslegungskapazität der Batterie bei Vollladung (in μAh)
Im folgenden UML-Diagramm finden Sie die für die Health-HAL-Implementierung nützlichen Klassen:
Abbildung 7. Health HAL 2.1 UML-Diagramm
Informationen zur Implementierung des Health-Service 2.1 finden Sie unter Implementieren von Health 2.1 .
AIDL HAL-Schnittstelle Version 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 ändert sich in der API Folgendes:
- In HIDL HAL 2.1 eingeführte ladegerätbezogene APIs werden nicht auf AIDL HAL portiert. Da die Funktionalität des Off-Mode-Ladens nur auf der
/vendor
Partition verfügbar ist, sind APIs auf der Vendor-Schnittstelle nicht erforderlich. Informationen zum ordnungsgemäßen Laden im Off-Modus finden Sie im Ladegerät unten. - Der Typ
StorageAttribute
und zugehörige Felder werden entfernt, da sie nicht verwendet werden. -
chargerDockOnline
wurde zuHealthInfo
hinzugefügt, um das Laden über die Dockingstation zu unterstützen.
Implementierung
Im folgenden UML-Diagramm finden Sie die für die Health-HAL-Implementierung nützlichen Klassen:
Abbildung 8. Health AIDL HAL UML-Diagramm
Informationen zur Implementierung des Health AIDL-Dienstes finden Sie unter Implementieren von Health AIDL HAL .
Erholung
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 zur Installation des Health AIDL-Dienstes zur Wiederherstellung finden Sie hier:
Ladegerät
Die Funktionalität des Off-Mode-Ladens wird von /system
nach /vendor
verschoben. Bei Geräten, die mit Android 13 gestartet werden und das Laden im Off-Modus unterstützen, muss die Binärdatei des HAL-Dienstes den Lademodus unterstützen. Weitere Informationen hierzu finden Sie unter Implementierung des Ladegeräts .
Eigenschaften des Ladegerätsystems
Die Eigenschaften ro.charger.*
sind für die charger
Binärdatei in /vendor
nicht mehr lesbar. Wenn für Ihr Gerät eine der Systemeigenschaften ro.charger.*
festgelegt ist, sehen Sie sich die Systemeigenschaften für das Ladegerät an.
Android 9 enthält android.hardware.health
HAL 2.0, ein Hauptversions-Upgrade von health@1.0 HAL. Dieser neue HAL bietet folgende Vorteile:
- Sauberere Trennung zwischen Framework und Anbietercode.
- Veraltet den unnötigen
healthd
Daemon. - Größere Freiheitsgrade bei der 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. Dieser neue HAL bietet folgende Vorteile:
- Einfacher umzusetzen
- Bessere Konformität mit bestehenden 2.0 HAL APIs
- Bessere Höhentrennung im Aus-Modus-Ladecode
- Bessere Unterstützung für das Framework zur Anzeige des Batteriezustands des Geräts
Android 13 enthält android.hardware.health
AIDL HAL, eine Konvertierung von health@2.1 HAL. Dieser neue HAL bietet folgende Vorteile:
- Entfernen Sie nicht verwendete ladegerätbezogene APIs
- Entfernen Sie nicht verwendetes
StorageAttribute
und zugehörige Felder - Unterstützt das Aufladen über die Dockingstation.
Anforderungen
Geräte mit Android 9 und Android 10
Geräte, die mit Android 9 gestartet werden, müssen den 2.x-HAL (und dürfen den 1.0-HAL nicht bereitstellen) oder den AIDL-HAL bereitstellen. Geräte, die nicht mit Android 9 gestartet werden, aber planen, das Hersteller-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 des 2.0 HAL und beim Übergang vom alten 1.0 HAL helfen sollen.
Geräte mit Android 11 und Android 12
Geräte, die mit Android 11 gestartet werden, müssen den 2.1 HAL (und dürfen nicht den 1.0 oder 2.0 HAL bereitstellen) oder den AIDL HAL bereitstellen. Geräte, die nicht mit Android 11 gestartet werden, aber planen, das Hersteller-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 gestartet werden und keine Aktualisierung des Anbieter-Images planen, wird ebenfalls empfohlen, den 2.1 HAL bereitzustellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung des 2.1 HAL und beim Übergang vom 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 Hersteller-Image auf Target Framework Compatibility Matrix Version 7 (veröffentlicht in Android 13) zu aktualisieren, müssen vorhandene HIDL HAL-Implementierungen entfernen und AIDL HAL bereitstellen. Für Geräte, die nicht mit Android 13 gestartet werden und keine Aktualisierung des Anbieter-Images planen, wird ebenfalls empfohlen, den AIDL HAL bereitzustellen.
Geräte dürfen HIDL 1.0 HAL nicht bereitstellen.
AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung des 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, veröffentlicht in Android 8.0. - health@2.0 : Abkürzung für
android.hardware.health@2.0
. Bezieht sich auf die in Android 9 veröffentlichte Health HIDL HAL Version 2.0. - health@2.1 : Abkürzung für
android.hardware.health@2.1
. Bezieht sich auf die in Android 11 veröffentlichte Health HIDL HAL Version 2.1. - Gesundheit AIDL HAL : Abkürzung für
android.hardware.health
.- Version 1 wird in Android 13 veröffentlicht.
- Ladegerät : Ausführbare Datei, die im ausgeschalteten Lademodus ausgeführt wird und die Animation zum Aufladen des Telefons anzeigt.
- Wiederherstellung : 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 diese dem Framework bereitstellt.
- storaged : In Android ausgeführter Daemon, der Speicherinformationen abruft und dem Framework bereitstellt.
Gesundheit in Android 8.x
In Android 8.x funktioniert die Gesundheitskomponente 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 zur Kommunikation mit der Hardware verwendet.
-
healthd
ist statisch mitlibhealthd_android
,libbatterymonitor
undlibbatteryservice
verknüpft. - health@1.0-impl verknüpft statisch mit
libhealthd. BOARD
.
Jedes Board kann eine andere libhealthd. BOARD
; Es wird zum Zeitpunkt der Erstellung festgelegt, zu welchem Ladegerät, Health@1.0-impl und Wiederherstellung eine Verknüpfung besteht.
Für andere Modi:
Abbildung 2. Zustand in Android 8.x, Lade- und Wiederherstellungsmodus im ausgeschalteten Zustand
- Das Ladegerät ist statisch mit
libhealthd. BOARD
,libhealthd_charger
undlibbatterymonitor
. - Die Wiederherstellung ist statisch mit
libhealthd. BOARD
undlibbatterymonitor
.
Gesundheit in Android 9
In Android 9 funktioniert die Gesundheitskomponente wie im folgenden Diagramm beschrieben:
Figur 3 . Gesundheit in Android 9
Das Framework versucht, den Health@2.0-Dienst von hwservicemanager
abzurufen. Wenn dies fehlschlägt, wird „health@1.0“ (in Android 8.x) aufgerufen. Der Legacy-Codepfad wird beibehalten, sodass das Android 9-System-Image mit dem Android 8.x-Anbieter-Image 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 ausgeschalteten Zustand
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) ] |
+-------------------------------------+
Die verschiedenen Modi finden Sie im folgenden vereinfachten Diagramm:
Abbildung 5. Health HAL 2.1-Infrastruktur
Gesundheit in Android 13
In Android 13 wird das Gesundheits-AIDL HAL eingeführt. Die Gesundheitskomponente funktioniert wie im folgenden Diagramm beschrieben:
Abbildung 6. Health AIDL HAL-Infrastruktur
HIDL HAL-Schnittstelle 2.0
Der Health@2.0-HAL bietet dem Framework die gleiche Funktionalität wie der alte Healthd-Daemon. Es stellt außerdem APIs bereit, die denen ähneln, die Healthd zuvor als Binder-Dienst 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
bereit, um herstellerspezifische speicherbezogene Informationen abzurufen:
-
getStorageInfo
-
getDiskStats
Eine neue Struktur, @2.0::HealthInfo
, wird über Rückrufe und getHealthInfo
zurückgegeben. Diese Struktur enthält alle über health@2.0 HAL verfügbaren Informationen zum Gerätezustand, einschließlich:
- Ladeinformationen (AC/USB/kabellos, Strom, Spannung usw.)
- Batterieinformationen (Anwesenheit, Batteriestand, Strom, Spannung, Ladung, Technologie usw.)
- Speicherinformationen (Informationen zum Speichergerät, Festplattenstatistiken)
Informationen zur Implementierung des Health Service 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 Off-Modus und liefert weitere Informationen über den Akku.
Die Hauptschnittstelle IHealth bietet die folgenden zusätzlichen Funktionen
-
getHealthConfig
: um die Konfiguration dieser HAL abzurufen -
getHealthInfo_2_1
: ein Nebenversions-Upgrade aufgetHealthInfo
-
shouldKeepScreenOn
: um zu bestimmen, 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 Funktionen registerCallback
und unregisterCallback
zu unterstützen. Die neue Rückrufschnittstelle gibt Gesundheitsinformationen mithilfe ihrer Funktion healthInfoChanged_2_1
“ anstelle der geerbten Funktion „ healthInfoChanged
an den Client zurück.
Eine neue Struktur, @2.1::HealthInfo
, wird über Rückrufe und getHealthInfo_2_1
zurückgegeben. Diese Struktur enthält zusätzliche Informationen zum Gerätezustand, die über health@2.0 HAL verfügbar sind, darunter:
- Batteriekapazitätsniveau
- Jetzt dauert es, bis der Akku vollständig aufgeladen ist (in Sekunden)
- Auslegungskapazität der Batterie bei Vollladung (in μAh)
Im folgenden UML-Diagramm finden Sie die für die Health-HAL-Implementierung nützlichen Klassen:
Abbildung 7. Health HAL 2.1 UML-Diagramm
Informationen zur Implementierung des Health-Service 2.1 finden Sie unter Implementieren von Health 2.1 .
AIDL HAL-Schnittstelle Version 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 ändert sich in der API Folgendes:
- In HIDL HAL 2.1 eingeführte ladegerätbezogene APIs werden nicht auf AIDL HAL portiert. Da die Funktionalität des Off-Mode-Ladens nur auf der
/vendor
Partition verfügbar ist, sind APIs auf der Vendor-Schnittstelle nicht erforderlich. Informationen zum ordnungsgemäßen Laden im Off-Modus finden Sie im Ladegerät unten. - Der Typ
StorageAttribute
und zugehörige Felder werden entfernt, da sie nicht verwendet werden. -
chargerDockOnline
wurde zuHealthInfo
hinzugefügt, um das Laden über die Dockingstation zu unterstützen.
Implementierung
Im folgenden UML-Diagramm finden Sie die für die Health-HAL-Implementierung nützlichen Klassen:
Abbildung 8. Health AIDL HAL UML-Diagramm
Informationen zur Implementierung des Health AIDL-Dienstes finden Sie unter Implementieren von Health AIDL HAL .
Erholung
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 zur Installation des Health AIDL-Dienstes zur Wiederherstellung finden Sie hier:
Ladegerät
Die Funktionalität des Off-Mode-Ladens wird von /system
nach /vendor
verschoben. Bei Geräten, die mit Android 13 gestartet werden und das Laden im Off-Modus unterstützen, muss die Binärdatei des HAL-Dienstes den Lademodus unterstützen. Weitere Informationen hierzu finden Sie unter Implementierung des Ladegeräts .
Eigenschaften des Ladegerätsystems
Die Eigenschaften ro.charger.*
sind für die charger
Binärdatei in /vendor
nicht mehr lesbar. Wenn für Ihr Gerät eine der Systemeigenschaften ro.charger.*
festgelegt ist, sehen Sie sich die Systemeigenschaften für das Ladegerät an.