Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Android-Systemstatus
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Android 13 enthält android.hardware.health AIDL HAL, eine Umwandlung von health@2.1 HAL. Diese neue HAL bietet folgende Vorteile:

Nicht verwendete ladegerätebezogene APIs entfernen
Nicht verwendete StorageAttribute und zugehörige Felder entfernen
Unterstützt das Aufladen per Dock.

Android 11 enthält android.hardware.health HAL 2.1, ein Minor-Versionsupgrade von health@2.0 HAL. Diese neue HAL bietet folgende Vorteile:

Bessere Trennung zwischen Framework- und Anbietercode.
Mehr Flexibilität bei der Anpassung von Berichten zu Gesundheitsinformationen durch Anbieter.
Nicht nur Informationen zum Akkuzustand, sondern auch zum Gerätezustand

Eine entsprechende Dokumentation finden Sie auf dieser Seite.

Voraussetzungen

Dieser Abschnitt enthält Anforderungen für Android 11, 12 und 13 oder höher.

Geräte mit Android 11 und Android 12

Geräte, die mit Android 11 und 12 auf den Markt kommen, müssen die 2.1 HAL oder die AIDL HAL bereitstellen. Bei Geräten, die nicht mit Android 11 oder 12 eingeführt werden, aber das Anbieter-Image auf die Target Framework Compatibility Matrix Version 5 (veröffentlicht in Android 11) oder 6 (veröffentlicht in Android 12) aktualisieren sollen, müssen vorhandene HAL-Implementierungen der Version 2.0 entfernt und die HAL der Version 2.1 oder die AIDL HAL bereitgestellt werden. Für Geräte, die nicht mit Android 11 auf den Markt kommen und für die das Anbieter-Image nicht aktualisiert werden soll, wird ebenfalls empfohlen, die HAL 2.1 oder AIDL bereitzustellen.

AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung der 2.1-HAL und der Umstellung von den alten HIDL-HALs helfen sollen.

Geräte mit Android 13 und höher

Geräte, die mit Android 13 auf den Markt gebracht werden, müssen die AIDL HAL bereitstellen (und dürfen keine HIDL HAL bereitstellen). Bei Geräten, die nicht mit Android 13 eingeführt werden, aber das Anbieter-Image auf die Target Framework Compatibility Matrix Version 7 (veröffentlicht in Android 13) aktualisieren sollen, müssen vorhandene HIDL HAL-Implementierungen entfernt und die AIDL HAL bereitgestellt werden. Für Geräte, die nicht mit Android 13 eingeführt werden und für die kein Update des Anbieter-Images geplant ist, wird ebenfalls empfohlen, die AIDL HAL bereitzustellen.

AOSP enthält mehrere Hilfsbibliotheken, die Ihnen bei der Implementierung der AIDL HAL und der Umstellung von den alten HIDL HALs helfen sollen.

Terminologie

Im Folgenden finden Sie Begriffe, die Sie kennen sollten, bevor Sie den Rest der Dokumentation zur Systemgesundheit von Android lesen:

health@2.1: Abkürzung von android.hardware.health@2.1. Version 1 der Health-HIDL wurde in Android 11 veröffentlicht.
health AIDL HAL: Abkürzung von android.hardware.health. Version 1 der Health AIDL HAL wurde in Android 13 veröffentlicht.
Ladegerät: Ausführbares Programm, das im Lademodus „Aus“ ausgeführt wird und die Ladeanimation des Smartphones anzeigt.
recovery: Ausführbares Programm, das im Wiederherstellungsmodus ausgeführt wird und Akkuinformationen abrufen muss.
storaged: Daemon, der Speicherinformationen abruft und an das Framework weitergibt.

Google Fit unter Android 11 und 12

Unter Android 11 und 12 funktioniert die Dienstbereitschaftskomponente wie im folgenden Diagramm dargestellt:

[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)      ] |
+-------------------------------------+

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)      ] |
+-------------------------------------+

Im folgenden vereinfachten Diagramm sind die verschiedenen Modi dargestellt:

Health HIDL HAL 2.1-Infrastruktur

Abbildung 1: Health HIDL HAL 2.1-Infrastruktur

Google Fit in Android 13

In Android 13 wird die HAL für den Gesundheits-AIDL eingeführt. Abbildung 2 zeigt, wie die Gesundheitskomponente funktioniert:

Health AIDL HAL-Infrastruktur

Abbildung 2: Health AIDL HAL-Infrastruktur

HIDL HAL-Schnittstelle 2.1

Die HAL von health@2.1 unterstützt das Aufladen im Aus-Modus und liefert mehr Informationen zum Akku.

Die Hauptoberfläche, IHealth, bietet die folgenden zusätzlichen Funktionen:

getHealthConfig: um die Konfiguration dieser HAL abzurufen
getHealthInfo_2_1: ein Upgrade auf die Nebenversion getHealthInfo
shouldKeepScreenOn: Ob das Display im Lademodus eingeschaltet bleiben soll

Außerdem muss @2.1::IHealth implementiert werden, damit @2.1::IHealthInfoCallback die übergeordneten Funktionen registerCallback und unregisterCallback unterstützen kann. Die neue Callback-Benutzeroberfläche gibt dem Client Informationen zum Gesundheitsstatus mithilfe der Funktion healthInfoChanged_2_1 zurück, anstatt die übergeordnete Funktion healthInfoChanged zu verwenden.

Ein neues @2.1::HealthInfo-Objekt wird mithilfe von Callbacks und getHealthInfo_2_1 zurückgegeben. Diese Struktur enthält zusätzliche Informationen zum Gerätestatus, die über die health@2.0 HAL verfügbar sind, darunter:

Akkukapazität
Akkuladezeit bis zur vollständigen Aufladung (in Sekunden)
Nennkapazität des Akkus bei voller Ladung (in μAh)

Abbildung 3 zeigt ein UML-Diagramm der Klassen, die für die HAL-Implementierung für Gesundheit nützlich sind:

Health 2.1 HAL-UML-Diagramm

Abbildung 3: UML-Diagramm für Health HAL 2.1

Informationen zur Implementierung des Diensts „Systemstatus 2.1“ finden Sie unter Systemstatus 2.1 implementieren.

AIDL HAL-Schnittstellenversion 1

Dieser Abschnitt enthält Informationen zur AIDL HAL-Schnittstelle Version 1.

API-Änderungen

Die HAL von AIDL Version 1 unterstützt ähnliche APIs wie die HAL von HIDL 2.1. Im Vergleich zur HIDL 2.1-Schnittstelle wurden in der API folgende Änderungen vorgenommen:

Ladegerätebezogene APIs, die in HIDL HAL 2.1 eingeführt wurden, werden nicht in die AIDL HAL portiert. Da die Funktion zum Laden im Aus-Modus nur auf der Partition /vendor vorhanden ist, sind APIs auf der Anbieterschnittstelle nicht erforderlich. Informationen zum korrekten Implementieren des Ladevorgangs im Aus-Modus finden Sie unter Ladegerät.
Der Typ StorageAttribute und die zugehörigen Felder werden entfernt, da sie nicht verwendet werden.
chargerDockOnline wird HealthInfo hinzugefügt, um das Laden im Dock zu unterstützen.

Implementierung

Abbildung 4 zeigt ein UML-Diagramm der Klassen, die für die HAL-Implementierung von Health AIDL nützlich sind:

Health AIDL HAL UML-Diagramm

Abbildung 4: Health AIDL HAL UML-Diagramm.

Informationen zur Implementierung des Health-AIDL-Dienstes finden Sie unter Implementing Health AIDL HAL (Health-AIDL-HAL implementieren).

Recovery

Android 13 unterstützt den Binder in der Wiederherstellung. Wenn Sie den Health-AIDL-Dienst in der Wiederherstellung installieren, kann er im Wiederherstellungsmodus ausgeführt werden.

Informationen zum Installieren des Health-AIDL-Dienstes in der Wiederherstellung finden Sie unter den folgenden Links:

Ladegerät

Die Funktion zum Laden im Aus-Modus wird von /system zu /vendor verschoben. Bei Geräten, die mit Android 13 auf den Markt kommen und das Aufladen im ausgeschalteten Zustand unterstützen, muss die HAL-Dienst-Binärdatei den Lademodus unterstützen. Weitere Informationen finden Sie unter Ladegerät implementieren.

Eigenschaften des Ladesystems

Die Properties ro.charger.* können nicht mehr vom charger-Binärcode in /vendor gelesen werden. Wenn auf Ihrem Gerät eine der ro.charger.*-Systemeigenschaften festgelegt ist, lesen Sie den Hilfeartikel Systemeigenschaften für Ladegeräte.

Android-Systemstatus Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.