Wdrożenie Health 2.1

W Androidzie 11 cały kod healthd został przeniesiony do bibliotek libhealthloop i libhealth2impl, a następnie zmodyfikowany w celu implementacji interfejsu HAL health@2.1. Te 2 biblioteki są statycznie połączone przez health@2.0-impl-2.1, czyli implementację passthrough interfejsu Health 2.1. Biblioteki połączone statycznie umożliwiają health@2.0-impl-2.1 wykonywanie tych samych zadań co healthd, np. uruchamianie healthd_mainloop i sondowanie. W init usługa health@2.1-service rejestruje implementację interfejsu IHealth w hwservicemanager. Podczas uaktualniania urządzeń z obrazem dostawcy Androida 8.x lub 9 i platformą Androida 11 obraz dostawcy może nie udostępniać usługi health@2.1. Zgodność wsteczna ze starymi obrazami dostawcy jest wymuszana przez harmonogram wycofywania.

Aby zapewnić zgodność wsteczną:

  1. Pomimo że healthd jest demonem systemowym, rejestruje IHealth w hwservicemanager. IHealth jest dodawany do manifestu systemu z nazwą instancji „backup”.
  2. Platforma i storaged komunikują się z healthd za pomocą hwbinder zamiast binder.
  3. Kod platformy i storaged jest zmieniany tak, aby pobierać instancję „default”, jeśli jest dostępna, a następnie „backup”.
    • Kod klienta C++ używa logiki zdefiniowanej w libhealthhalutils.
    • Kod klienta Java używa logiki zdefiniowanej w HealthServiceWrapper.
  4. Gdy IHealth/default będzie powszechnie dostępny, a obrazy dostawcy Androida 8.1 zostaną wycofane, można wycofać IHealth/backup i healthd.

Zmienne kompilacji specyficzne dla płyty w przypadku healthd

BOARD_PERIODIC_CHORES_INTERVAL_* to zmienne specyficzne dla płyty używane do kompilowania healthd. W ramach podziału kompilacji systemu i dostawcy nie można definiować wartości specyficznych dla płyty w przypadku modułów systemowych. nie można Te wartości były wcześniej zastępowane w wycofanej funkcji healthd_board_init.

W health@2.1 dostawcy mogą zastąpić te 2 wartości interwału okresowych zadań w strukturze healthd_config przed przekazaniem ich do konstruktora klasy implementacji stanu. Klasa implementacji stanu powinna dziedziczyć po android::hardware::health::V2_1::implementation::Health.

Implementowanie usługi Health 2.1

Informacje o implementowaniu usługi Health 2.1 znajdziesz w pliku hardware/interfaces/health/2.1/README.md.

Klienci stanu

health@2.x ma tych klientów:

  • charger Użycie kodu libbatterymonitor i healthd_common jest opakowane w health@2.0-impl.
  • recovery Połączenie z libbatterymonitor jest opakowane w health@2.0-impl. Wszystkie wywołania BatteryMonitor są zastępowane wywołaniami klasy implementacji Health.

  • BatteryManager BatteryManager.queryProperty(int id) był jedynym klientem IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty był udostępniany przez healthd i bezpośrednio odczytywał /sys/class/power_supply.

    Ze względów bezpieczeństwa aplikacje nie mogą bezpośrednio wywoływać interfejsu HAL stanu. W Androidzie 9 i nowszych usługa binder IBatteryPropertiesRegistrar jest udostępniana przez BatteryService zamiast healthd. BatteryService przekazuje wywołanie do interfejsu HAL stanu, aby pobrać żądane informacje.

  • BatteryService W Androidzie 9 i nowszych BatteryService używa HealthServiceWrapper, aby określić, czy użyć domyślnej instancji usługi stanu z vendor, czy zapasowej instancji usługi stanu z healthd. BatteryService nasłuchuje zdarzeń stanu za pomocą IHealth.registerCallback.

  • Storaged W Androidzie 9 i nowszych storaged używa libhealthhalutils, aby określić, czy użyć domyślnej instancji usługi stanu z vendor, czy zapasowej instancji usługi stanu z healthd. storaged nasłuchuje zdarzeń stanu za pomocą IHealth.registerCallback i pobiera informacje o pamięci.

Zmiany w SELinux

Interfejs HAL health@2.1 obejmuje te zmiany w SELinux na platformie:

  • Dodaje android.hardware.health@2.1-service do file_contexts.

W przypadku urządzeń z własną implementacją mogą być konieczne pewne zmiany w SELinux dostawcy. Przykład:

# 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.

Interfejsy jądra

Demon healthd i domyślna implementacja android.hardware.health@2.0-impl-2.1 uzyskują dostęp do tych interfejsów jądra, aby pobrać informacje o baterii:

  • /sys/class/power_supply/*/capacity_level (dodano w 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 (dodano w 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 (dodano w Health 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Każda implementacja interfejsu HAL stanu specyficzna dla urządzenia, która używa libbatterymonitor, domyślnie uzyskuje dostęp do tych interfejsów jądra, chyba że zostanie zastąpiona w konstruktorze klasy implementacji stanu.

Jeśli te pliki są niedostępne lub nie można do nich uzyskać dostępu z poziomu healthd lub domyślnej usługi (np. plik jest symlinkiem do folderu specyficznego dla dostawcy, który odmawia dostępu z powodu nieprawidłowo skonfigurowanej zasady SELinux), mogą one nie działać prawidłowo. Dlatego nawet w przypadku używania domyślnej implementacji mogą być konieczne dodatkowe zmiany w SELinux specyficzne dla dostawcy.

Niektóre interfejsy jądra używane w Health 2.1, takie jak /sys/class/power_supply/*/capacity_level i /sys/class/power_supply/*/time_to_full_now, mogą być opcjonalne. Aby jednak zapobiec nieprawidłowemu działaniu platformy wynikającemu z braku interfejsów jądra, przed skompilowaniem usługi Health HAL 2.1 zalecamy wybranie CL 1398913.

Testowanie

Android 11 zawiera nowe testy VTS napisane specjalnie dla interfejsu HAL health@2.1. Jeśli urządzenie deklaruje interfejs HAL health@2.1 w manifeście urządzenia, musi przejść odpowiednie testy VTS. Testy są pisane zarówno dla instancji domyślnej (aby mieć pewność, że urządzenie prawidłowo implementuje interfejs HAL), jak i zapasowej (aby mieć pewność, że healthd nadal działa prawidłowo przed jego usunięciem).

Wymagania dotyczące informacji o baterii

Interfejs HAL Health 2.0 określa zestaw wymagań dotyczących interfejsu HAL, ale odpowiednie testy VTS są stosunkowo łagodne w ich egzekwowaniu. W Androidzie 11 dodano nowe testy VTS, aby wymusić te wymagania na urządzeniach wprowadzonych na rynek z Androidem 11 lub nowszym:

  • Jednostki chwilowego i średniego prądu baterii muszą być mikroamperami (μA).
  • Znak chwilowego i średniego prądu baterii musi być prawidłowy. W szczególności:
    • current == 0, gdy stan baterii to UNKNOWN
    • current > 0, gdy stan baterii to CHARGING
    • current <= 0, gdy stan baterii to NOT_CHARGING
    • current < 0, gdy stan baterii to DISCHARGING
    • Nie jest wymuszane, gdy stan baterii to FULL
  • Stan baterii musi być prawidłowy w zależności od tego, czy źródło zasilania jest podłączone. W szczególności:
    • stan baterii musi być jednym z tych stanów: CHARGING, NOT_CHARGING lub FULL, tylko wtedy, gdy źródło zasilania jest podłączone;
    • stan baterii musi być DISCHARGING, tylko wtedy, gdy źródło zasilania jest odłączone.

Jeśli w implementacji używasz libbatterymonitor i przekazujesz wartości z interfejsów jądra, upewnij się, że węzły sysfs zgłaszają prawidłowe wartości:

  • Upewnij się, że prąd baterii jest zgłaszany z prawidłowym znakiem i jednostkami. Obejmuje to te węzły sysfs:
    • /sys/class/power_supply/*/current_avg
    • /sys/class/power_supply/*/current_max
    • /sys/class/power_supply/*/current_now
    • Wartości dodatnie wskazują prąd wpływający do baterii.
    • Wartości powinny być podawane w mikroamperach (μA).
  • Upewnij się, że napięcie baterii jest zgłaszane w mikrowoltach (μV). Obejmuje to te węzły sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Pamiętaj, że domyślna implementacja interfejsu HAL dzieli voltage_now przez 1000 i zgłasza wartości w miliwoltach (mV). Zobacz @1.0::HealthInfo.

Więcej informacji znajdziesz w artykule o klasie zasilania systemu Linux .