Gesundheit umsetzen 2.1

In Android 11 wird der gesamte healthd -Code in libhealthloop und libhealth2impl umgestaltet und dann modifiziert, um die HAL health@2.1 zu implementieren. Diese beiden Bibliotheken werden statisch von health@2.0-impl-2.1 , der Passthrough-Implementierung von health 2.1, verknüpft. Die statisch verknüpften Bibliotheken ermöglichen es health@2.0-impl-2.1 , die gleiche Arbeit wie healthd zu erledigen, z. B. das Ausführen von healthd_mainloop und 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 bietet das Anbieter-Image möglicherweise nicht den health@2.1-Dienst. Abwärtskompatibilität mit alten Anbieter-Images wird durch den Ablaufplan erzwungen.

Um die Abwärtskompatibilität zu gewährleisten:

  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 anstelle von binder .
  3. Der Code für framework und storaged wird geändert, um die Instanz „default“ abzurufen, falls verfügbar, dann „backup“.
    • C++-Clientcode verwendet die in libhealthhalutils definierte Logik.
    • Java-Clientcode verwendet die in HealthServiceWrapper definierte Logik.
  4. Nachdem IHealth/default allgemein verfügbar ist und Android 8.1-Herstellerimages veraltet sind, können IHealth/backup und healthd veraltet sein. Weitere Einzelheiten finden Sie unter Verwerfen von health@1.0 .

Boardspezifische Build-Variablen für healthd

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

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

Implementieren 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 Clients:

  • Ladegerät . Die Verwendung von libbatterymonitor und healthd_common Code ist in health@2.0-impl .
  • Erholung . Die Verknüpfung mit libbatterymonitor ist in health@2.0-impl . 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 direkt gelesen /sys/class/power_supply .

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

  • BatterieService . In Android 9 und höher verwendet BatteryService HealthServiceWrapper , um zu bestimmen, ob die standardmäßige Integritätsdienstinstanz des vendor oder die Backup -Integritätsdienstinstanz von healthd werden soll. BatteryService wartet dann über IHealth.registerCallback auf Zustandsereignisse.

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

SELinux-Änderungen

Die HAL health@2.1 enthält die folgenden SELinux-Änderungen in der Plattform:

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

Für Geräte 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 Daemon healthd 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 (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 Integritäts-HAL-Implementierung, die libbatterymonitor verwendet, greift standardmäßig auf diese Kernel-Schnittstellen zu, sofern sie nicht im Klassenkonstruktor der Integritätsimplementierung überschrieben wird.

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

Einige Kernel-Schnittstellen, die in Health 2.1 verwendet werden, wie etwa /sys/class/power_supply/*/capacity_level und /sys/class/power_supply/*/time_to_full_now , können optional sein. Um jedoch falsches Framework-Verhalten aufgrund fehlender Kernel-Schnittstellen zu verhindern, wird empfohlen, CL 1398913 herauszupicken , bevor der Health HAL 2.1-Dienst erstellt wird.

Testen

Android 11 enthält neue VTS-Tests , die speziell für die 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 Sicherungsinstanz (um sicherzustellen, dass healthd weiterhin ordnungsgemäß funktioniert, bevor es entfernt wird) geschrieben.

Anforderungen an Batterieinformationen

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

  • Die Einheit des momentanen und durchschnittlichen Batteriestroms muss Mikroampere (μA) sein.
  • Das Vorzeichen des momentanen und mittleren Batteriestroms muss korrekt sein. Speziell:
    • Strom == 0, wenn der Batteriestatus UNKNOWN ist
    • Strom > 0, wenn der Batteriestatus CHARGING ist
    • Strom <= 0, wenn der Batteriestatus NOT_CHARGING ist
    • Strom < 0, wenn der Batteriestatus DISCHARGING ist
    • 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 CHARGING , NOT_CHARGING oder FULL sein, wenn und nur wenn eine Stromquelle angeschlossen ist;
    • Der Batteriestatus muss DISCHARGING wenn und nur wenn eine Stromquelle getrennt ist.

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

  • Stellen Sie sicher, dass der Batteriestrom mit dem richtigen Vorzeichen und den richtigen Einheiten gemeldet 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 standardmäßige HAL-Implementierung voltage_now durch 1000 dividiert und Werte in Millivolt (mV) meldet. Siehe @1.0::HealthInfo .

Einzelheiten finden Sie unter Linux-Netzteilklasse .