Android-Gesundheit

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 mit libhealthd_android , libbatterymonitor und libbatteryservice 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 und libbatterymonitor .
• Die Wiederherstellung ist statisch mit libhealthd. BOARD und libbatterymonitor .

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 , 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 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 auf getHealthInfo
• 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 zu HealthInfo 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:

• Verwenden Sie den Beispieldienst Health AIDL HAL
• Erstellen Sie Systemänderungen

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 mit libhealthd_android , libbatterymonitor und libbatteryservice 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 und libbatterymonitor .
• Die Wiederherstellung ist statisch mit libhealthd. BOARD und libbatterymonitor .

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 , 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 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 auf getHealthInfo
• 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 zu HealthInfo 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:

• Verwenden Sie den Beispieldienst Health AIDL HAL
• Erstellen Sie Systemänderungen

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.