Implement Health 2.1

In Android 11 wird der gesamte healthd-Code in libhealthloop und libhealth2impl, dann geändert zur Implementierung von health@2.1 HAL. Diese beiden Bibliotheken sind über health@2.0-impl-2.1 statisch verknüpft. die Passthrough-Implementierung von Health 2.1. Die statisch verknüpften Bibliotheken health@2.0-impl-2.1 aktivieren, um dieselben Aufgaben wie healthd zu erledigen, z. B. healthd_mainloop und Abfragen. Bei Init registriert die health@2.1-service eine Implementierung der Schnittstelle IHealth zu hwservicemanager. Beim Upgrade Geräte mit Android 8.x oder 9 Anbieterbild und ein Android 11-Framework, Das Anbieter-Image bietet möglicherweise nicht den Dienst health@2.1. Rückwärts wird die Kompatibilität mit alten Anbieter-Images durch den Zeitplan für die Einstellung.

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

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

Board-spezifische Build-Variablen für fehlerfreie

BOARD_PERIODIC_CHORES_INTERVAL_* sind boardspezifische Variablen, die zum Erstellen von healthd. Im Rahmen der Aufteilung zwischen System und Anbieter werden branchenspezifische Werte nicht für Systemmodule definiert. Diese Werte wurden zuvor überschrieben in der verworfenen Funktion healthd_board_init.

In Health@2.1 können Anbieter die diese beiden periodischen Aufgabenintervalle in der Struktur healthd_config davor wird an den Konstruktor der Gesundheitsimplementierungsklasse übergeben. Der Status Implementierungsklasse soll von android::hardware::health::V2_1::implementation::Health

Health 2.1-Dienst implementieren

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

Gesundheitskundschaft

Health@2.x hat die folgenden Clients:

  • Ladegerät. Die Verwendung des Codes libbatterymonitor und healthd_common ist umschlossen in health@2.0-impl.
  • Wiederherstellung. Die Verknüpfung zu libbatterymonitor ist umschlossen in health@2.0-impl. Alle BatteryMonitor-Aufrufe werden durch Aufrufe von ersetzt in Implementierungsklasse Health.

  • BatteryManager BatteryManager.queryProperty(int id) war der einzige Client von IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty wurde zur Verfügung gestellt von healthd und hat /sys/class/power_supply direkt gelesen.

    Aus Sicherheitsgründen dürfen Apps keine HAL in den Systemzustand aufrufen . Unter Android 9 und höher Dienst IBatteryPropertiesRegistrar wird von BatteryService bereitgestellt statt healthd. BatteryService delegiert den Aufruf an die HAL-Funktion. um die angeforderten Informationen abzurufen.

  • BatteryService Unter Android 9 und höher BatteryService verwendet HealthServiceWrapper, um zu bestimmen, ob die Methode Systemdiagnose-Instanz default von vendor oder zur Verwendung der Sicherung Systemdiagnose-Instanz von healthd erstellt. BatteryService erfasst dann Gesundheitsereignisse bis IHealth.registerCallback.

  • Gespeichert: Unter Android 9 und höher storaged verwendet libhealthhalutils, um zu bestimmen, ob die Methode Systemdiagnose-Instanz default von vendor oder zur Verwendung der Sicherung Systemdiagnose-Instanz von healthd erstellt. storaged dann überwacht Gesundheitsereignisse über IHealth.registerCallback und ruft Speicherinformationen.

SELinux-Änderungen

Der Health@2.1-HAL beinhaltet die folgenden SELinux-Änderungen auf der Plattform:

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

Bei Geräten mit eigener Implementierung können einige SELinux-Anbieteränderungen notwendig ist. 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.

Kernelschnittstellen

Den Daemon healthd und die Standardimplementierung android.hardware.health@2.0-impl-2.1 greift auf die folgenden Kernel-Schnittstellen zu, um Akkuinformationen abrufen:

  • /sys/class/power_supply/*/capacity_level (in Health 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 Health 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 Health 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, die libbatterymonitor verwendet greift standardmäßig auf diese Kernel-Schnittstellen zu, sofern sie im Systemstatus nicht überschrieben wird Implementierungsklassenkonstruktor.

Wenn diese Dateien fehlen oder über healthd oder das Standarddienst (z. B. ist die Datei ein Symlink zu einem anbieterspezifischen Ordner die den Zugriff aufgrund einer falsch konfigurierten SELinux-Richtlinie verweigert, ordnungsgemäß funktioniert. Zusätzliche anbieterspezifische SELinux-Änderungen obwohl die Standardimplementierung verwendet wird.

Einige Kernel-Schnittstellen, die in Health 2.1 verwendet werden, z. B. /sys/class/power_supply/*/capacity_level und /sys/class/power_supply/*/time_to_full_now ist möglicherweise optional. Um jedoch verhindert falsches Framework-Verhalten, das durch fehlende Kernel-Schnittstellen verursacht wird. empfiehlt es sich, ein Kirschpflücken CL 1398913 bevor der Health HAL 2.1-Dienst erstellt wird.

Testen

Android 11 enthält neue VTS-Tests speziell für Health@2.1 HAL. Wenn ein Gerät deklariert, state@2.1 HAL im Gerätemanifest auf, muss es die entsprechenden VTS-Tests bestehen. Tests werden sowohl für die Standardinstanz geschrieben, um sicherzustellen, dass das Gerät den HAL korrekt implementiert) und die Sicherungsinstanz, um sicherzustellen, dass healthd weiterhin ordnungsgemäß funktioniert, bevor es entfernt wird).

Anforderungen an Akkuinformationen

Der Health 2.0 HAL gibt eine Reihe von Anforderungen an die HAL-Benutzeroberfläche an, aber der bei der Erzwingung der VTS-Tests relativ entspannt. In Android 11 werden neue VTS-Tests hinzugefügt, um die folgenden Anforderungen für Geräte, die mit Android auf den Markt gebracht werden 11 und höher:

  • Die Einheit für den intarsischen und durchschnittlichen Batteriestrom muss Mikroamp (μA) sein.
  • Das Zeichen des momentanen und durchschnittlichen Batteriestroms muss korrekt sein. Im Detail: <ph type="x-smartling-placeholder">
      </ph>
    • current == 0, wenn der Akkustatus UNKNOWN ist
    • Aktuell > 0, wenn der Akkustatus „CHARGING“ ist
    • „aktuell <= 0“, wenn der Akkustand NOT_CHARGING ist
    • Aktuell < 0, wenn der Akkustatus „DISCHARGING“ ist
    • Wird nicht erzwungen, wenn der Akkustatus „FULL“ ist
  • Der Batteriestatus muss korrekt sein, unabhängig davon, ob eine Stromquelle verbunden. Im Detail: <ph type="x-smartling-placeholder">
      </ph>
    • Der Akkustatus muss CHARGING, NOT_CHARGING oder FULL sein, wenn und nur, wenn eine Stromquelle angeschlossen ist,
    • Der Akkustatus muss DISCHARGING lauten, wenn eine Stromquelle mit nicht verbunden.

Wenn Sie libbatterymonitor in Ihrer Implementierung verwenden und Werte übergeben von den Kernel-Schnittstellen überprüfen, ob die Sysfs-Knoten die richtigen Werte melden:

  • Stelle sicher, dass der Batteriestrom mit dem richtigen Zeichen und den richtigen Einheiten gemeldet wird. Dieses enthält die folgenden sysfs-Knoten: <ph type="x-smartling-placeholder">
      </ph>
    • /sys/class/power_supply/*/current_avg
    • /sys/class/power_supply/*/current_max
    • /sys/class/power_supply/*/current_now
    • Positive Werte zeigen an, dass der Akku mit Strom versorgt wird.
    • Die Werte sollten in Mikroamps (μA) angegeben werden.
  • Die Batteriespannung muss in Mikrovolt (μV) angegeben werden. Dazu gehören die folgende Sysfs-Knoten: <ph type="x-smartling-placeholder">
      </ph>
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Beachten Sie, dass die Standard-HAL-Implementierung voltage_now durch 1.000 dividiert und gibt die Werte in Millivolt (mV) an. Weitere Informationen finden Sie unter @1.0::HealthInfo.

Weitere Informationen finden Sie unter Linux-Netzteilklasse