Android-Systemzustand

Android 9 enthält android.hardware.health HAL 2.0, ein Major-Versionsupgrade von health@1.0 HAL. Diese neue HAL bietet folgende Vorteile:

  • Bessere Trennung zwischen Framework- und Anbietercode.
  • Der unnötige healthd-Daemon wird eingestellt.
  • Mehr Flexibilität bei der Anpassung von Berichten zu Gesundheitsinformationen durch Anbieter.
  • Nicht nur Informationen zum Akkuzustand, sondern auch zum Gerätezustand

Android 11 enthält android.hardware.health HAL 2.1, ein Nebenversionsupgrade von health@2.0 HAL. Dieser neue HAL hat die folgenden Vorteile:

  • Einfachere Implementierung
  • Bessere Konformität mit vorhandenen HAL-APIs 2.0
  • Bessere Trennung von Treble im Ladecode im Ruhemodus
  • Bessere Unterstützung des Frameworks zur Anzeige des Akkuzustands des Geräts

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 Felder für „StorageAttribute“ und zugehörige Felder entfernen
  • Unterstützt das Aufladen per Dock.

Voraussetzungen

Geräte mit Android 9 und Android 10

Geräte, die mit Android 9 ausgeliefert werden, müssen die 2.x HAL (nicht die 1.0 HAL) oder die AIDL HAL bereitstellen. Bei Geräten, die nicht mit Android 9 auf den Markt gebracht werden, aber das Anbieter-Image auf Version 3 der Target Framework Compatibility Matrix Version 3 (veröffentlicht in Android 9) aktualisiert werden soll, müssen vorhandene 1.0-HAL-Implementierungen entfernt und 2.x-HAL oder AIDL HAL bereitgestellt werden.

AOSP enthält mehrere Hilfsbibliotheken, die Sie bei der Implementierung der 2.0 HAL und der Umstellung von der alten 1.0 HAL unterstützen.

Geräte mit Android 11 und Android 12

Geräte, die mit Android 11 auf den Markt kommen, müssen die HAL 2.1 (nicht die HAL 1.0 oder 2.0) oder die AIDL HAL bereitstellen. Bei Geräten, die nicht mit Android 11 auf den Markt gekommen sind, aber das Anbieter-Image auf Version 5 der Target Framework Compatibility Matrix Version 5 (veröffentlicht in Android 11) aktualisiert werden soll, müssen vorhandene 2.0-HAL-Implementierungen entfernt und 2.1 HAL oder AIDL HAL bereitgestellt werden. Bei Geräten, die nicht mit Android 11 auf den Markt gebracht werden und keine Aktualisierung des Anbieter-Images geplant ist, wird außerdem empfohlen, HAL 2.1 bereitzustellen.

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

Geräte mit Android 13 oder 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 unter Android 13 auf den Markt gebracht werden, aber das Anbieter-Image auf Version 7 der Target Framework Compatibility Matrix Version 7 (veröffentlicht in Android 13) aktualisiert werden soll, müssen vorhandene HIDL HAL-Implementierungen entfernt und 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.

Geräte dürfen nicht die HIDL 1.0 HAL bereitstellen.

AOSP enthält mehrere Hilfsbibliotheken, die Sie bei der Implementierung des AIDL HAL und der Umstellung von den alten HIDL HALs unterstützen.

Terminologie

  • health@1.0: Abkürzung für android.hardware.health@1.0. Bezieht sich auf die HIDL HAL-Version 1.0 für Gesundheit, die in Android 8.0 veröffentlicht wurde.
  • health@2.0: Abkürzung für android.hardware.health@2.0. Bezieht sich auf die HIDL HAL-Version 2.0 für Gesundheit, die in Android 9 veröffentlicht wurde.
  • health@2.1: Abkürzung für android.hardware.health@2.1. Bezieht sich auf die Integrität von HIDL HAL Version 2.1, die in Android 11 veröffentlicht wurde.
  • health AIDL HAL: Abkürzung für android.hardware.health.
    • Version 1 wird mit Android 13 veröffentlicht.
  • charger: ausführbares Programm, das im Lademodus ausgeführt wird und die Ladeanimation für das Smartphone anzeigt
  • recovery: Ausführbares Programm, das im Wiederherstellungsmodus ausgeführt wird und Akkuinformationen abrufen muss.
  • healthd: Legacy-Daemon, der unter Android ausgeführt wird und gesundheitsbezogene Informationen abruft und dem Framework zur Verfügung stellt.
  • storaged: Ein unter Android ausgeführter Daemon, der Speicherinformationen abrufen und an das Framework weitergeben kann.

Google Fit unter Android 8.x

In Android 8.x funktioniert die Zustandskomponente wie im folgenden Diagramm dargestellt:

Google Fit unter Android 8.x

Abbildung 1 Google Fit unter Android 8.x

In diesem Diagramm:

  • Ein (1) Binder-Aufruf und ein (1) Hwbinder-Aufruf werden vom Framework für die Kommunikation mit der Hardware verwendet.
  • healthd ist statisch mit libhealthd_android, libbatterymonitor und libbatteryservice verknüpft.
  • health@1.0-impl verweist statisch auf libhealthd.BOARD.

Für jedes Board kann eine andere libhealthd.BOARD angepasst werden. Beim Build wird festgelegt, welches Ladegerät, welche health@1.0-Implementierung und welcher Wiederherstellungslink verwendet werden soll.

Für andere Modi:

Laden im Aus-Modus und Wiederherstellungsmodus unter Android 8.x

Abbildung 2. Akkuzustand in Android 8.x, Laden im Aus-Modus und Wiederherstellungsmodus

  • „Ladegerät“ ist statisch mit libhealthd.BOARD, libhealthd_charger und libbatterymonitor verknüpft.
  • recovery ist statisch mit libhealthd.BOARD und libbatterymonitor verknüpft.

Gesundheit in Android 9

In Android 9 funktioniert die Zustandskomponente wie im folgenden Diagramm dargestellt: Google Fit unter Android 9

Abbildung 3 Google Fit in Android 9

Das Framework versucht, den health@2.0-Dienst von hwservicemanager abzurufen. Wenn der Vorgang fehlschlägt, wird health@1.0 (in Android 8.x) aufgerufen. Der Pfad für den alten Code wird beibehalten, damit das Android 9-System-Image mit dem Android 8.x-Anbieter-Image kompatibel ist. Das Framework ruft keine Informationen aus beiden HALs ab, da auf dem Gerät nur eine Dienstversion (1.0 oder 2.0) vorhanden sein kann.

Für andere Modi:

Laden und Wiederherstellen im Aus-Modus unter Android 9

Abbildung 4: Akkuzustand in Android 9, Aufladen im Aus-Modus und Wiederherstellungsmodus

Google Fit in Android 11

In Android 11 funktioniert die Dienstqualitätskomponente 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)      ] |
+-------------------------------------+

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

Im folgenden vereinfachten Diagramm sind die verschiedenen Modi dargestellt:

Health HAL 2.1-Infrastruktur

Abbildung 5: Health HAL 2.1-Infrastruktur

Google Fit in Android 13

In Android 13 wird die Health AIDL HAL eingeführt. Die Funktionsweise der Gesundheitskomponente ist im folgenden Diagramm dargestellt:

Health AIDL HAL-Infrastruktur

Abbildung 6 Health AIDL HAL-Infrastruktur

HIDL HAL-Schnittstelle 2.0

Der Health@2.0-HAL bietet dem Framework die gleichen Funktionen wie der alte fehlerfreie Daemon. Außerdem bietet es ähnliche APIs wie IBatteryPropertiesRegistrar, die zuvor als Binder-Dienst bereitgestellt wurden.

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

  • registerCallback, um IBatteryPropertiesRegistrar.registerListener zu ersetzen
  • unregisterCallback, um IBatteryPropertiesRegistrar.unregisterListener zu ersetzen
  • update, um IBatteryPropertiesRegistrar.scheduleUpdate zu ersetzen
  • IBatteryPropertiesRegistrar.getProperties durch Folgendes ersetzt:
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

Darüber hinaus bietet IHealth die folgenden neuen APIs für storaged, um anbieterspezifische speicherbezogene Informationen abzurufen:

  • getStorageInfo
  • getDiskStats

Über Callbacks und getHealthInfo wird ein neuer Datentyp, @2.0::HealthInfo, zurückgegeben. Diese Struktur enthält alle Informationen zum Gerätezustand, die über health@2.0 HAL verfügbar sind, darunter:

  • Ladeinformationen (AC/USB/kabellos, Strom, Spannung usw.)
  • Akkuinformationen (Vorhandensein, Akkustand, Strom, Spannung, Ladung, Technologie usw.)
  • Speicherinformationen (Speichergeräteinformationen, Laufwerksstatistiken)

Informationen zur Implementierung des Health-Dienstes 2.0 finden Sie unter Health 2.0 implementieren.

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 Hauptschnittstelle IHealth bietet die folgenden zusätzlichen Funktionen

  • getHealthConfig: zum Abrufen der Konfiguration dieses HAL
  • 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-Schnittstelle gibt mit der healthInfoChanged_2_1-Funktion anstelle der übernommenen healthInfoChanged-Funktion Informationen zum Gesundheitszustand an den Client zurück.

Über Callbacks und getHealthInfo_2_1 wird ein neuer Datentyp @2.1::HealthInfo zurückgegeben. Diese Struktur enthält zusätzliche Informationen zum Gerätezustand, die über health@2.0 HAL verfügbar sind, darunter:

  • Akkukapazität
  • Akkuladezeit bis zum vollen Akku (in Sekunden)
  • Nennkapazität des Akkus bei voller Ladung (in μAh)

Im folgenden UML-Diagramm sind die Klassen zu sehen, die für die Implementierung der HAL für Gesundheit nützlich sind:

Health 2.1 HAL UML-Diagramm

Abbildung 7: 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-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 für das Aufladen im alternativen Modus nur auf der Partition /vendor verfügbar ist, sind keine APIs auf der Anbieterschnittstelle erforderlich. Weitere Informationen zum korrekten Laden im Aus-Modus finden Sie unten unter Ladegerät.
  • Der Typ StorageAttribute und zugehörige Felder werden entfernt, da sie nicht verwendet werden.
  • chargerDockOnline wird HealthInfo hinzugefügt, um das Laden im Dock zu unterstützen.

Implementierung

Im folgenden UML-Diagramm sind die Klassen zu sehen, die für die Implementierung der HAL für Gesundheit nützlich sind:

Integritäts-AIDL HAL UML-Diagramm

Abbildung 8. Health AIDL HAL UML-Diagramm.

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

Wiederherstellung

Android 13 unterstützt Binder im Wiederherstellungsmodus. 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 für das Laden im Offlinemodus wurde von /system auf /vendor verschoben. Wenn Geräte, die mit Android 13 auf den Markt kommen, 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 Ladegerätsystems

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.