Android-Systemzustand

Android 9 umfasst android.hardware.health HAL 2.0, ein Hauptversions-Upgrade von health@1.0 HAL. Dieser neue HAL hat Folgendes: Vorteile:

  • Klarere Trennung zwischen Framework- und Anbietercode.
  • Der unnötige Daemon healthd wird verworfen.
  • Mehr Freiheit bei der Anpassung von Gesundheitsinformationen an Anbieter Berichte.
  • Mehr Informationen zum Gerätestatus als nur der Akku

Android 11 umfasst android.hardware.health HAL 2.1, ein Nebenversions-Upgrade von health@2.0 HAL. Dieser neue HAL hat Folgendes: Vorteile:

  • Einfachere Implementierung
  • Bessere Konformität mit vorhandenen HAL-APIs 2.0
  • Bessere Höhentrennung bei Ladecode im Offlinemodus
  • Bessere Unterstützung für das Framework, um den Akkuzustand des Geräts anzuzeigen. Gerät

Android 13 enthält android.hardware.health AIDL HAL, eine Conversion von health@2.1 HAL. Dieser neue HAL hat Folgendes: Vorteile:

  • Nicht verwendete APIs für Ladegeräte entfernen
  • Nicht verwendete Felder für „StorageAttribute“ und zugehörige Felder entfernen
  • Das Laden des Docks wird unterstützt.

Voraussetzungen

Geräte mit Android 9 und Android 10

Geräte, die mit Android 9 auf den Markt gebracht werden, müssen über Version 2.x verfügen HAL (und darf nicht 1.0 HAL bereitstellen) oder AIDL HAL. Geräte lassen sich nicht starten mit Android 9, aber planen, das Anbieter-Image zu aktualisieren. auf Version 3 der Target Framework Compatibility Matrix (veröffentlicht in Android 9) vorhandene 1.0-HAL-Implementierungen entfernen und die 2.x-HAL oder die AIDL HAL bereitstellen.

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

Geräte mit Android 11 und Android 12

Geräte, die mit Android 11 auf den Markt gebracht werden, müssen über Version 2.1 verfügen. HAL (und darf nicht 1.0 oder 2.0 HAL bereitstellen) oder AIDL HAL. Geräte nicht die mit Android 11 auf den Markt kommt, Bild des Anbieters zur Target Framework Compatibility Matrix Version 5 (veröffentlicht im Android 11) muss die vorhandene 2.0-HAL-Datei entfernen Implementierungen und stellen Sie den 2.1 HAL oder den AIDL HAL bereit. Geräte lassen sich nicht starten mit Android 11 arbeiten und nicht vorhaben, den Anbieter zu aktualisieren, wird außerdem empfohlen, die 2.1 HAL-Datei bereitzustellen.

AOSP enthält mehrere Hilfsbibliotheken, die Sie bei der Implementierung von 2.1 HAL und die Umstellung von der alten 1.0-HAL.

Geräte mit Android 13 und höher

Geräte, die mit Android 13 auf den Markt gebracht werden, müssen die AIDL bereitstellen HAL (und darf HIDL HAL nicht bereitstellen). Geräte, die nicht mit Android 13 auf den Markt gebracht werden, für die jedoch eine Aktualisierung des Anbieter-Images auf „Target“ geplant ist Framework Compatibility Matrix Version 7 (veröffentlicht in Android 13) muss vorhandene HIDL HAL-Implementierungen entfernen und stellen Sie die AIDL HAL bereit. Bei Geräten, die nicht mit Android 13 auf den Markt gebracht werden und keine Aktualisierung des Anbieter-Images geplant ist, wird empfohlen, den AIDL HAL bereitzustellen.

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

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

Terminologie

  • health@1.0: Abkürzung für android.hardware.health@1.0. Bezieht sich auf Zustand 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 Zustand HIDL HAL Version 2.0, veröffentlicht in Android 9.
  • health@2.1: Abkürzung für android.hardware.health@2.1. Bezieht sich auf Zustand HIDL HAL Version 2.1, veröffentlicht in Android 11.
  • health AIDL HAL: Abkürzung für android.hardware.health.
    • Version 1 wird in Android 13 veröffentlicht.
  • charger: ausführbare Datei, die im deaktivierten Modus ausgeführt wird und die eine Animation beim Laden des Smartphones.
  • recovery: ausführbare Datei, die im Wiederherstellungsmodus ausgeführt wird und den Akku abrufen muss Informationen.
  • healthd: unter Android ausgeführter Legacy-Daemon, der gesundheitsbezogene Informationen und stellt sie als Rahmen dar.
  • storaged: Unter Android ausgeführter Daemon, der Speicherinformationen abruft und stellt es zum Framework bereit.

Gesundheit in Android 8.x

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

Gesundheit in Android 8.x

Abbildung 1: Gesundheit in Android 8.x

In diesem Diagramm gilt Folgendes:

  • Ein (1) Binder-Aufruf und ein (1) Hwbinder-Aufruf werden vom Framework verwendet, um mit Hardware kommunizieren können.
  • healthd verknüpft mit libhealthd_android, libbatterymonitor und libbatteryservice.
  • Health@1.0-impl verlinkt statisch zu libhealthd.BOARD

Jedes Board kann ein anderes libhealthd.BOARD anpassen. Bei der Build-Erstellung wird bestimmt, welches Ladegerät, welches Health@1.0-impl-Gerät und welcher Wiederherstellungslink verwendet werden sollen. an.

Für andere Mobilitätsformen:

Lade- und Wiederherstellungsmodus im deaktivierten Modus unter Android 8.x

Abbildung 2: Gesundheit unter Android 8.x, Lade- und Wiederherstellungsmodus im deaktivierten Modus.

  • Das Ladegerät ist statisch mit libhealthd.BOARD verbunden. libhealthd_charger und libbatterymonitor.
  • die Wiederherstellung statisch mit libhealthd.BOARD und libbatterymonitor.

Gesundheit in Android 9

In Android 9 funktioniert die Zustandskomponente wie im Detail im folgenden Diagramm: Gesundheit in Android 9

Abbildung 3. Gesundheit in Android 9

Das Framework versucht, den Health@2.0-Dienst von hwservicemanager abzurufen. Wenn er fehlschlägt, ruft er health@1.0 (in Android 8.x) auf. Der Legacy-Codepfad ist beibehalten, damit das Android 9-System-Image mit das Anbieter-Image für Android 8.x. Das Framework ruft keine Informationen beide HALs, da nur eine Dienstversion (1.0 oder 2.0) auf dem Gerät vorhanden sein kann.

Für andere Mobilitätsformen:

Laden und Wiederherstellung im deaktivierten Modus unter Android 9

Abbildung 4: Gesundheit unter Android 9, Lade- und Wiederherstellungsmodus im deaktivierten Modus.

Gesundheit in Android 11

In Android 11 funktioniert die Komponente „Gesundheit“ wie im Detail im folgenden Diagramm:

[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 Systemdiagnose 2.1 nicht vorhanden ist, greift das System auf den Legacy-Codepfad wie in den vorherigen Abschnitten beschrieben

Für andere Mobilitätsformen:

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

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 der Zustands-AIDL HAL eingeführt. Die funktioniert wie im folgenden Diagramm beschrieben:

Health AIDL HAL-Infrastruktur

Abbildung 6: Zustand der AIDL HAL-Infrastruktur.

HIDL HAL-Schnittstelle 2.0

Der Health@2.0-HAL bietet dem Framework die gleichen Funktionen wie das alte fehlerfreien Daemon verwendet. Außerdem bietet es APIs, die denen ähneln, zuvor als Binderdienst angeboten wurde (d.h. IBatteryPropertiesRegistrar)

Die Hauptoberfläche, IHealth bietet die folgenden Funktionen:

  • registerCallback, zum Ersetzen IBatteryPropertiesRegistrar.registerListener
  • unregisterCallback, zum Ersetzen IBatteryPropertiesRegistrar.unregisterListener
  • update, um IBatteryPropertiesRegistrar.scheduleUpdate zu ersetzen
  • IBatteryPropertiesRegistrar.getProperties werden durch Folgendes ersetzt: <ph type="x-smartling-placeholder">
      </ph>
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

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

  • getStorageInfo
  • getDiskStats

Die neue Struktur @2.0::HealthInfo wird über Callbacks und getHealthInfo zurückgegeben. Diese Struktur enthält alle Informationen zum Gerätestatus, die über health@2.0 verfügbar sind HAL, einschließlich:

  • Ladeinformationen (AC/USB/drahtlos, Strom, Spannung usw.)
  • Akkuinformationen (Präsenz, Akkustand, Strom, Spannung, Akkustand, Technologie usw.)
  • Speicherinformationen (Informationen zu Speichergeräten, Laufwerksstatistiken)

Informationen zum Implementieren des Health Service 2.0 finden Sie unter Implementierung von Health 2.0

HIDL HAL-Schnittstelle 2.1

Der Health@2.1 HAL unterstützt das Laden im ausgeschalteten Modus und bietet weitere Informationen über den Akku.

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

  • getHealthConfig: zum Abrufen der Konfiguration dieses HAL
  • getHealthInfo_2_1: ein Nebenversionsupgrade auf getHealthInfo
  • shouldKeepScreenOn: um zu bestimmen, ob der Bildschirm eingeschaltet bleiben soll, Lademodus

Außerdem ist die Implementierung von @2.1::IHealth erforderlich, um @2.1::IHealthInfoCallback für die übernommenen registerCallback und unregisterCallback-Funktionen. Die neue Callback-Oberfläche gibt den Systemzustand zurück Informationen an den Client mit der Funktion healthInfoChanged_2_1 statt die übernommene healthInfoChanged-Funktion.

Die neue Struktur @2.1::HealthInfo wird über Callbacks zurückgegeben und getHealthInfo_2_1. Diese Struktur enthält zusätzliche Informationen zum Gerätezustand verfügbar über health@2.0 HAL, darunter:

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

Im folgenden UML-Diagramm sind die Klassen aufgeführt, die für die HAL-Implementierung des Systemstatus nützlich sind:

Health 2.1 HAL UML-Diagramm

Abbildung 7: Health HAL 2.1 UML-Diagramm.

Informationen zum Implementieren des Health Service 2.1 finden Sie unter Implementierung von Health 2.1:

AIDL HAL-Schnittstellenversion 1

API-Änderungen

AIDL Version 1 HAL unterstützt ähnliche APIs wie HIDL 2.1 HAL. Verglichen mit der HIDL 2.1-Schnittstelle wird Folgendes in der API geändert:

  • Ladegerätbezogene APIs, die in HIDL HAL 2.1 eingeführt wurden, werden nicht in die AIDL portiert HAL. Da das Laden im Offlinemodus nur auf der /vendor-Partition sind keine APIs auf der Anbieterschnittstelle erforderlich. Bis sollten Sie das Aufladen im Offline-Modus korrekt implementieren, siehe Ladegerät unten.
  • Der Typ „StorageAttribute“ und zugehörige Felder wurden entfernt, weil nicht verwendet werden.
  • „chargerDockOnline“ wird „HealthInfo“ hinzugefügt, um das Laden des Docks zu unterstützen.

Implementierung

Im folgenden UML-Diagramm sind die Klassen aufgeführt, die für die HAL-Implementierung des Systemstatus nützlich sind:

Integritäts-AIDL HAL UML-Diagramm

Abbildung 8: Integritäts-AIDL HAL UML-Diagramm.

Informationen zum Implementieren des Gesundheits-AIDL-Dienstes finden Sie unter Implementieren von Health AIDL HAL.

Recovery

Android 13 unterstützt Binder bei der Wiederherstellung. Installieren der Der Health AIDL-Dienst für die Wiederherstellung ermöglicht die Ausführung im Wiederherstellungsmodus.

Informationen zum Installieren des AIDL-Gesundheitsdienstes für die Wiederherstellung finden Sie in der Folgendes:

Ladegerät

Die Funktion für das Laden im Offlinemodus wurde von /system auf /vendor verschoben. Für Geräte, die mit Android 13 auf den Markt gebracht werden, sofern sie dies unterstützen sollte das HAL-Dienstbinärprogramm den Lademodus unterstützen. Gehen Sie dazu wie folgt vor: siehe zur Implementierung des Ladegeräts.

Eigenschaften des Ladegerätsystems

Die Attribute ro.charger.* können nicht mehr von der Binärdatei charger gelesen werden in /vendor Wenn auf deinem Gerät eine der Systemeigenschaften von ro.charger.* festgelegt ist: siehe Systemeigenschaften des Ladegeräts.