Health 2.1 implementieren

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

In Android 11 wird der gesamte healthd-Code in libhealthloop und libhealth2impl umgeschrieben und dann so geändert, dass die HAL für health@2.1 implementiert wird. Diese beiden Bibliotheken werden statisch von health@2.0-impl-2.1 verknüpft, der Passthrough-Implementierung von Health 2.1. Dank der statisch verknüpften Bibliotheken kann health@2.0-impl-2.1 dieselben Aufgaben wie healthd ausführen, z. B. healthd_mainloop ausführen und abfragen. In init registriert health@2.1-service eine Implementierung der Schnittstelle IHealth bei hwservicemanager. Beim Upgrade von Geräten mit einem Anbieter-Image von Android 8.x oder 9 und einem Android 11-Framework wird der Dienst „health@2.1“ möglicherweise nicht vom Anbieter-Image bereitgestellt. Die Abwärtskompatibilität mit alten Anbieterbildern wird durch den Zeitplan für die Einstellung erzwungen.

So sorgen Sie für Abwärtskompatibilität:

1. healthd registriert IHealth bei hwservicemanager, obwohl es sich um einen System-Daemon handelt. IHealth wird dem Systemmanifest mit dem Instanznamen „backup“ hinzugefügt.
2. Das Framework und storaged kommunizieren mit healthd über hwbinder anstelle von binder.
3. Der Code für „framework“ und storaged wird geändert, um die Instanz „default“ abzurufen, falls verfügbar, und dann „backup“.
   • Der C++-Clientcode verwendet die in libhealthhalutils definierte Logik.
   • Der Java-Clientcode verwendet die in HealthServiceWrapper definierte Logik.
4. Sobald IHealth/default weithin verfügbar ist und Android 8.1-Anbieterbilder eingestellt werden, können IHealth/backup und healthd eingestellt werden. Weitere Informationen finden Sie unter Einstellung von health@1.0.

Boardspezifische Buildvariablen für healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sind plattformspezifische Variablen, die zum Erstellen von healthd verwendet werden. Im Rahmen der Aufteilung in System- und Anbieterbuilds können für Systemmodule keine plattformspezifischen Werte definiert werden. Diese Werte wurden früher in der eingestellten Funktion healthd_board_init überschrieben.

In health@2.1 können Anbieter diese beiden Intervallwerte für regelmäßige Aufgaben im healthd_config-Typ überschreiben, bevor sie an den Konstruktor der Health-Implementierungsklasse übergeben werden. Die Klasse für die Dienstbereitschaftsimplementierung muss von android::hardware::health::V2_1::implementation::Health abgeleitet sein.

Health 2.1-Dienst implementieren

Informationen zur Implementierung des Health 2.1-Dienstes finden Sie unter hardware/interfaces/health/2.1/README.md.

Gesundheitskunden

health@2.x hat die folgenden Clients:

• Ladegerät Die Verwendung von libbatterymonitor- und healthd_common-Code ist in health@2.0-impl eingehüllt.
• recovery. Die Verknüpfung mit libbatterymonitor ist in health@2.0-impl verpackt. Alle Aufrufe von BatteryMonitor werden durch Aufrufe der Implementierungsklasse Health ersetzt.

• BatteryManager BatteryManager.queryProperty(int id) war der einzige Kunde von IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty wurde von healthd bereitgestellt und /sys/class/power_supply wurde direkt gelesen.

  Aus Sicherheitsgründen dürfen Apps die HAL für Gesundheit nicht direkt aufrufen. Unter Android 9 und höher wird der Binderdienst IBatteryPropertiesRegistrar von BatteryService anstelle von healthd bereitgestellt. BatteryService delegiert den Aufruf an die Health HAL, um die angeforderten Informationen abzurufen.

• BatteryService Unter Android 9 und höher verwendet BatteryService HealthServiceWrapper, um zu bestimmen, ob die Standard-Systemdiagnoseinstanz von vendor oder die Sicherungs-Systemdiagnoseinstanz von healthd verwendet werden soll. BatteryService wartet dann über IHealth.registerCallback auf Gesundheitsereignisse.

• Storaged Unter Android 9 und höher verwendet storaged libhealthhalutils, um zu bestimmen, ob die Standard-Systemdiagnoseinstanz von vendor oder die Sicherungs-Systemdiagnoseinstanz von healthd verwendet werden soll. storaged prüft dann über IHealth.registerCallback auf Systemstatusereignisse und ruft Speicherinformationen ab.

SELinux-Änderungen

Der HAL für health@2.1 enthält die folgenden SELinux-Änderungen an der Plattform:

• Fügt android.hardware.health@2.1-service zu file_contexts hinzu.

Bei Geräten mit eigener Implementierung sind möglicherweise einige SELinux-Änderungen des Anbieters erforderlich. Beispiel:

# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.

Kernel-Schnittstellen

Der healthd-Daemon und die Standardimplementierung android.hardware.health@2.0-impl-2.1 greifen auf die folgenden Kernel-Schnittstellen zu, um Akkuinformationen abzurufen:

• /sys/class/power_supply/*/capacity_level (in Google Fit 2.1 hinzugefügt)
• /sys/class/power_supply/*/capacity
• /sys/class/power_supply/*/charge_counter
• /sys/class/power_supply/*/charge_full
• /sys/class/power_supply/*/charge_full_design (in Google Fit 2.1 hinzugefügt)
• /sys/class/power_supply/*/current_avg
• /sys/class/power_supply/*/current_max
• /sys/class/power_supply/*/current_now
• /sys/class/power_supply/*/cycle_count
• /sys/class/power_supply/*/health
• /sys/class/power_supply/*/online
• /sys/class/power_supply/*/present
• /sys/class/power_supply/*/status
• /sys/class/power_supply/*/technology
• /sys/class/power_supply/*/temp
• /sys/class/power_supply/*/time_to_full_now (in Google Fit 2.1 hinzugefügt)
• /sys/class/power_supply/*/type
• /sys/class/power_supply/*/voltage_max
• /sys/class/power_supply/*/voltage_now

Jede gerätespezifische HAL-Implementierung für den Gesundheitsstatus, die libbatterymonitor verwendet, greift standardmäßig auf diese Kernel-Schnittstellen zu, sofern dies nicht im Konstruktor der Health-Implementierungsklasse überschrieben wird.

Wenn diese Dateien fehlen oder von healthd oder dem Standarddienst nicht zugänglich sind (z. B. wenn die Datei ein Symlink zu einem anbieterspezifischen Ordner ist, der den Zugriff aufgrund einer falsch konfigurierten SELinux-Richtlinie verweigert), funktionieren sie möglicherweise nicht richtig. Daher sind möglicherweise zusätzliche anbieterspezifische SELinux-Änderungen erforderlich, auch wenn die Standardimplementierung verwendet wird.

Einige in Health 2.1 verwendete Kernelschnittstellen, z. B. /sys/class/power_supply/*/capacity_level und /sys/class/power_supply/*/time_to_full_now, sind möglicherweise optional. Um jedoch ein falsches Framework-Verhalten aufgrund fehlender Kernel-Schnittstellen zu vermeiden, wird empfohlen, CL 1398913 auszuwählen, bevor Sie den Health HAL 2.1-Dienst erstellen.

Testen

Android 11 enthält neue VTS-Tests, die speziell für die HAL von health@2.1 entwickelt wurden. Wenn ein Gerät im Gerätemanifest die HAL „health@2.1“ deklariert, muss es die entsprechenden VTS-Tests bestehen. Die Tests werden sowohl für die Standardinstanz (um sicherzustellen, dass das Gerät die HAL korrekt implementiert) als auch für die Sicherungs-Instanz (um sicherzustellen, dass healthd weiterhin ordnungsgemäß funktioniert, bevor sie entfernt wird) geschrieben.

Anforderungen an Akkuinformationen

Die Health 2.0 HAL legt eine Reihe von Anforderungen an die HAL-Schnittstelle fest, die entsprechenden VTS-Tests sind jedoch relativ locker bei der Durchsetzung. In Android 11 wurden neue VTS-Tests hinzugefügt, um die folgenden Anforderungen auf Geräten durchzusetzen, die mit Android 11 und höher auf den Markt gebracht werden:

• Die Einheiten für den momentanen und den durchschnittlichen Akkustrom müssen Mikroampere (μA) sein.
• Das Vorzeichen des momentanen und durchschnittlichen Akkustroms muss korrekt sein. Im Detail:
  • current == 0, wenn der Akkustand UNKNOWN ist
  • current > 0, wenn der Akkustatus CHARGING ist
  • current <= 0, wenn der Akkustand NOT_CHARGING ist
  • current < 0, wenn der Akkustand DISCHARGING ist
  • Nicht erzwungen, wenn der Akkustand FULL ist
• Der Akkustatus muss korrekt sein, unabhängig davon, ob eine Stromquelle angeschlossen ist. Im Detail:
  • Der Akkustatus muss CHARGING, NOT_CHARGING oder FULL sein, wenn und nur wenn eine Stromquelle angeschlossen ist.
  • Der Akkustatus muss DISCHARGING sein, wenn die Stromversorgung getrennt ist.

Wenn Sie libbatterymonitor in Ihrer Implementierung verwenden und Werte von Kernel-Schnittstellen weitergeben, achten Sie darauf, dass die sysfs-Knoten die richtigen Werte melden:

• Achten Sie darauf, dass der Akkustrom mit dem richtigen Vorzeichen und den richtigen Einheiten angegeben wird. Dazu gehören die folgenden sysfs-Knoten:
  • /sys/class/power_supply/*/current_avg
  • /sys/class/power_supply/*/current_max
  • /sys/class/power_supply/*/current_now
  • Positive Werte geben den Strom an, der in den Akku fließt.
  • Die Werte sollten in Mikroampere (μA) angegeben werden.
• Die Akkuspannung muss in Mikrovolt (μV) angegeben werden. Dazu gehören die folgenden sysfs-Knoten:
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now
  • Beachten Sie, dass die Standard-HAL-Implementierung voltage_now durch 1.000 teilt und Werte in Millivolt (mV) meldet. Weitere Informationen finden Sie unter @1.0::HealthInfo.

Weitere Informationen finden Sie unter Linux-Netzteilklasse.