Android-Gesundheit

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:

Gesundheit in Android 8.x

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 auf libhealthd_android , libbatterymonitor und libbatteryservice .
  • 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:

Lade- und Wiederherstellungsmodus im Aus-Modus in Android 8.x

Abbildung 2. Zustand in Android 8.x, Lade- und Wiederherstellungsmodus im Aus-Modus

  • Charger verlinkt statisch auf libhealthd. BOARD , libhealthd_charger und libbatterymonitor .
  • recovery verlinkt statisch auf libhealthd. BOARD und libbatterymonitor .

Gesundheit in Android 9

In Android 9 funktioniert die Health-Komponente wie im folgenden Diagramm beschrieben: Gesundheit in Android 9

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:

Laden und Wiederherstellen im Aus-Modus in Android 9

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:

Health HAL 2.1-Infrastruktur

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:

Gesundheit AIDL HAL-Infrastruktur

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 , um IBatteryPropertiesRegistrar.registerListener zu ersetzen
  • unregisterCallback , um IBatteryPropertiesRegistrar.unregisterListener zu ersetzen
  • update , um IBatteryPropertiesRegistrar.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 auf getHealthInfo
  • 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:

Health 2.1 HAL UML-Diagramm

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 wird HealthInfo 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:

Gesundheit 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 .

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 .