Gesundheit umsetzen 2.1

In Android 11 wird der gesamte healthd Code in libhealthloop und libhealth2impl umgestaltet und dann geändert, um die HAL von health@2.1 zu implementieren. Diese beiden Bibliotheken sind statisch verknüpft durch health@2.0-impl-2.1 , die Passthrough-Implementierung von Health 2.1. Die statisch verknüpften Bibliotheken ermöglichen es health@2.0-impl-2.1 die gleichen Aufgaben wie healthd auszuführen, z. B. das Ausführen healthd_mainloop und das Abfragen. In init registriert der health@2.1-service eine Implementierung der Schnittstelle IHealth zu hwservicemanager . Beim Upgrade von Geräten mit einem Android 8.x- oder 9-Anbieter-Image und einem Android 11-Framework stellt das Anbieter-Image möglicherweise nicht den Dienst „health@2.1“ bereit. Die Abwärtskompatibilität mit alten Anbieter-Images wird durch den Einstellungsplan erzwungen.

Um die Abwärtskompatibilität sicherzustellen:

  1. healthd registriert IHealth bei hwservicemanager , obwohl es sich um einen Systemdämon handelt. IHealth wird dem Systemmanifest mit dem Instanznamen „backup“ hinzugefügt.
  2. Das Framework und storaged kommunizieren mit healthd über hwbinder statt über binder .
  3. Der Code für Framework und storaged wird geändert, um die Instanz „default“, falls verfügbar, und dann „backup“ abzurufen.
    • C++-Clientcode verwendet die in libhealthhalutils definierte Logik.
    • Der Java-Clientcode verwendet die in HealthServiceWrapper definierte Logik.
  4. Nachdem IHealth/default allgemein verfügbar ist und Android 8.1-Anbieterimages veraltet sind, können IHealth/backup und healthd veraltet sein. Weitere Einzelheiten finden Sie unter „Veralten von Health@1.0“ .

Boardspezifische Build-Variablen für healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sind Board-spezifische Variablen, die zum Erstellen healthd verwendet werden. Im Rahmen der System-/Hersteller-Build-Aufteilung können für Systemmodule keine platinenspezifischen Werte definiert werden. Diese Werte wurden früher in der veralteten Funktion healthd_board_init überschrieben.

In Health@2.1 können Anbieter diese beiden Intervallwerte für periodische Aufgaben in der Struktur healthd_config überschreiben, bevor sie an den Konstruktor der Gesundheitsimplementierungsklasse übergeben werden. Die Gesundheitsimplementierungsklasse sollte von android::hardware::health::V2_1::implementation::Health erben.

Implementierung des Health 2.1-Dienstes

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

Gesundheitskunden

health@2.x hat folgende Kunden:

  • Ladegerät . Die Verwendung von libbatterymonitor healthd_common -Code ist health@2.0-impl eingeschlossen.
  • Erholung . Die Verknüpfung zu libbatterymonitor ist in health@2.0-impl verpackt. Alle Aufrufe von BatteryMonitor werden durch Aufrufe der Health Implementierungsklasse ersetzt.
  • BatterieManager . BatteryManager.queryProperty(int id) war der einzige Client von IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty wurde von healthd bereitgestellt und /sys/class/power_supply direkt gelesen.

    Aus Sicherheitsgründen ist es Apps nicht gestattet, Health HAL direkt aufzurufen. In Android 9 und höher wird der Binderdienst IBatteryPropertiesRegistrar von BatteryService anstelle von healthd bereitgestellt. BatteryService delegiert den Aufruf an die Gesundheits-HAL, um die angeforderten Informationen abzurufen.

  • BatterieService . In Android 9 und höher verwendet BatteryService HealthServiceWrapper , um zu bestimmen, ob die Standard- Instanz des Gesundheitsdiensts vom vendor oder die Backup- Instanz des Gesundheitsdiensts von healthd verwendet werden soll. BatteryService wartet dann über IHealth.registerCallback auf Gesundheitsereignisse.

  • Gespeichert . In Android 9 und höher verwendet storaged libhealthhalutils , um zu bestimmen, ob die Standardinstanz des Integritätsdiensts vom vendor oder die Backup- Instanz des Integritätsdiensts von healthd verwendet werden soll. storaged lauscht dann über IHealth.registerCallback auf Gesundheitsereignisse und ruft Speicherinformationen ab.

SELinux-Änderungen

Das Health@2.1 HAL beinhaltet die folgenden SELinux-Änderungen in der Plattform:

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

Für Geräte mit eigener Implementierung können einige SELinux-Änderungen des Anbieters erforderlich sein. 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 Batterieinformationen abzurufen:

  • /sys/class/power_supply/*/capacity_level (hinzugefügt in Health 2.1)
  • /sys/class/power_supply/*/capacity
  • /sys/class/power_supply/*/charge_counter
  • /sys/class/power_supply/*/charge_full
  • /sys/class/power_supply/*/charge_full_design (hinzugefügt in Health 2.1)
  • /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 (hinzugefügt in Health 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

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

Wenn diese Dateien fehlen oder über healthd oder den Standarddienst nicht zugänglich sind (z. B. handelt es sich bei der Datei um einen symbolischen Link zu einem herstellerspezifischen Ordner, der den Zugriff aufgrund einer falsch konfigurierten SELinux-Richtlinie verweigert), funktionieren sie möglicherweise nicht ordnungsgemäß. Daher können zusätzliche herstellerspezifische SELinux-Änderungen erforderlich sein, auch wenn die Standardimplementierung verwendet wird.

Einige in Health 2.1 verwendete Kernel-Schnittstellen, wie z /sys/class/power_supply/*/capacity_level und /sys/class/power_supply/*/time_to_full_now , sind möglicherweise optional. Um jedoch falsches Framework-Verhalten aufgrund fehlender Kernel-Schnittstellen zu verhindern, wird empfohlen, CL 1398913 auszuwählen, bevor der Health HAL 2.1-Dienst erstellt wird.

Testen

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

Anforderungen an Batterieinformationen

Das Health 2.0 HAL legt eine Reihe von Anforderungen an die HAL-Schnittstelle fest, die entsprechenden VTS-Tests gehen jedoch bei der Durchsetzung dieser Anforderungen relativ locker vor. In Android 11 werden neue VTS-Tests hinzugefügt, um die folgenden Anforderungen auf Geräten zu erzwingen, die mit Android 11 und höher gestartet werden:

  • Die Einheiten des momentanen und durchschnittlichen Batteriestroms müssen Mikroampere (μA) sein.
  • Das Vorzeichen des momentanen und durchschnittlichen Batteriestroms muss korrekt sein. Speziell:
    • Strom == 0, wenn der Batteriestatus UNKNOWN ist
    • Strom > 0, wenn der Batteriestatus CHARGING lautet
    • Strom <= 0, wenn der Batteriestatus NOT_CHARGING ist
    • Strom < 0, wenn der Batteriestatus DISCHARGING lautet
    • Wird nicht erzwungen, wenn der Batteriestatus FULL ist
  • Der Batteriestatus muss unabhängig davon, ob eine Stromquelle angeschlossen ist oder nicht, korrekt sein. Speziell:
    • Der Batteriestatus muss nur dann CHARGING , NOT_CHARGING oder FULL sein, wenn eine Stromquelle angeschlossen ist.
    • Der Batteriestatus muss nur dann DISCHARGING , wenn eine Stromquelle getrennt ist.

Wenn Sie libbatterymonitor in Ihrer Implementierung verwenden und Werte von Kernel-Schnittstellen weiterleiten, stellen Sie sicher, dass die sysfs-Knoten korrekte Werte melden:

  • Stellen Sie sicher, dass der Batteriestrom 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 zeigen an, dass Strom in die Batterie fließt.
    • Die Werte sollten in Mikroampere (μA) angegeben werden.
  • Stellen Sie sicher, dass die Batteriespannung in Mikrovolt (μV) angegeben wird. 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 1000 dividiert und Werte in Millivolt (mV) meldet. Siehe @1.0::HealthInfo .

Einzelheiten finden Sie unter Linux-Netzteilklasse .