Wdrażanie Health 2.1

W Androidzie 11 cały kod healthd jest refaktoryzowany na libhealthloop i libhealth2impl, a następnie modyfikowano w celu implementacji kodu Health@2.1 HAL. Te 2 biblioteki są statycznie połączone przez health@2.0-impl-2.1, przekazującej wdrożenie Health 2.1. Statycznie połączone biblioteki zezwól aplikacji health@2.0-impl-2.1 na wykonywanie tych samych czynności co healthd, np. uruchamianie healthd_mainloop i ankietowanie. W inicjowaniu moduł health@2.1-service rejestruje po wdrożeniu interfejsu IHealth do hwservicemanager. Podczas uaktualniania urządzeniach z Androidem 8.x lub 9, obraz dostawcy i platformę Androida 11, obraz dostawcy może nie udostępniać usługi Health@2.1. Wstecz zgodność ze starymi obrazami dostawcy jest wymuszana przez harmonogram wycofywania.

Aby zapewnić zgodność wsteczną:

  1. healthd rejestruje IHealth w hwservicemanager mimo korzystania z systemu demona. Do pliku manifestu systemowego dodano nazwę instancji IHealth z nazwą instancji „kopia zapasowa”.
  2. Platforma i storaged komunikują się z platformą healthd za pomocą hwbinder zamiast binder.
  3. Kod platformy i zasad storaged został zmieniony tak, aby pobrać instancję „domyślna” wybierz „kopia zapasowa”, jeśli ta opcja jest dostępna.
    • Kod klienta C++ korzysta z logiki zdefiniowanej w zasadzie libhealthhalutils.
    • Kod klienta w języku Java korzysta z logiki zdefiniowanej w zasadzie HealthServiceWrapper.
  4. Po powszechnej dostępności systemu IHealth/default oraz obrazów dostawców Androida 8.1 wycofane, IHealth/backup oraz healthd mogą zostać wycofane. Więcej szczegóły, patrz Wycofanie Health@1.0

Zmienne kompilacji dla konkretnej tablicy dla sprawnych

BOARD_PERIODIC_CHORES_INTERVAL_* to zmienne związane z płytką używane do tworzenia healthd W ramach podziału kompilacji systemu/dostawcy wartości dla poszczególnych płyt nie można zdefiniować dla modułów systemowych. Te wartości zostały zastąpione w wycofanej funkcji healthd_board_init.

W Health@2.1 dostawcy mogą zastąpić te 2 wartości interwału zadań okresowych w strukturze healthd_config przed do konstruktora klas implementacji stanu zdrowia. Zdrowie klasa implementacji powinna dziedziczyć z android::hardware::health::V2_1::implementation::Health

Wdrażanie usługi Health 2.1

Informacje o wdrażaniu usługi Health 2.1 znajdziesz tutaj hardware/interfaces/health/2.1/README.md.

Klienci ochrony zdrowia

Health@2.x ma tych klientów:

  • ładowarka. Korzystanie z kodu aplikacji libbatterymonitor i healthd_common jest zawijanie tekstu health@2.0-impl.
  • w przypadku odzyskiwania konta. Połączenie z usługą libbatterymonitor jest uwzględnione w zakresie health@2.0-impl Wszystkie połączenia z numerem BatteryMonitor są zastępowane połączeniami z: klasę implementacji Health.

  • BatteryManager. BatteryManager.queryProperty(int id) był jedynym klient domeny IBatteryPropertiesRegistrar.getProperty. Źródło: IBatteryPropertiesRegistrar.getProperty healthd i bezpośrednio przeczytaj: /sys/class/power_supply.

    Ze względów bezpieczeństwa aplikacje nie mogą wywoływać HAL dotyczących stanu zdrowia bezpośrednio. W Androidzie 9 i nowszych pakiet binarny usługa IBatteryPropertiesRegistrar jest świadczona przez BatteryService zamiast healthd. BatteryService przekazuje wywołanie do HAL ds. zdrowia w celu pobrania wymaganych informacji.

  • BatteryService. W Androidzie 9 i nowszych BatteryService używa HealthServiceWrapper do określenia, czy użyć domyślna instancja usługi stanu z usługi vendor lub do użycia kopii zapasowej instancję usługi stanu z healthd. BatteryService następnie nasłuchuje przez zdarzenia związane ze zdrowiem do IHealth.registerCallback.

  • Pamięć. W Androidzie 9 i nowszych storaged używa libhealthhalutils do określenia, czy użyć domyślna instancja usługi stanu z usługi vendor lub do użycia kopii zapasowej instancję usługi stanu z healthd. storaged, potem nasłuchuje zdarzeń związanych ze zdrowiem przez IHealth.registerCallback i pobiera z informacjami o pamięci masowej.

Zmiany w SELinux

HAL Health@2.1 zawiera następujące zmiany na platformie SELinux:

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

W przypadku urządzeń z własną implementacją niektóre zmiany dostawcy SELinux mogą niezbędną. 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 systemu

Demon healthd i implementacja domyślna android.hardware.health@2.0-impl-2.1 uzyskuje dostęp do poniższych interfejsów jądra, pobrania informacji 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 kontroli stanu HAL na danym urządzeniu, która korzysta z interfejsu libbatterymonitor domyślnie uzyskuje dostęp do tych interfejsów jądra, chyba że zostanie to zastąpione konstruktora klasy implementacji.

Jeśli nie ma tych plików lub są one niedostępne w usłudze healthd lub w domyślnej usługi (na przykład plik jest dowiązaniem symbolicznym do folderu konkretnego dostawcy; odmawia dostępu z powodu błędnie skonfigurowanej zasady SELinux), nie działa poprawnie. Dodatkowe zmiany SELinux związane z dostawcą mimo że jest używana implementacja domyślna.

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, może być opcjonalna. Jednak, aby: zapobiega nieprawidłowemu działaniu platformy wynikającemu z braku interfejsów jądra systemu zalecamy wybranie wiśni CL 1398913 przed utworzeniem usługi Health HAL 2.1.

Testowanie

Android 11 zawiera nowe Testy VTS napisane specjalnie na potrzeby HAL Health@2.1. Jeśli urządzenie zadeklaruje, Health@2.1 HAL w pliku manifestu urządzenia, musi przejść odpowiednie testy VTS. Testy są zapisywane dla instancji domyślnej (aby upewnić się, że urządzenie prawidłowo implementuje listę HAL) i instancję kopii zapasowej (aby zapewnić, że healthd będzie działał poprawnie przed jego usunięciem).

Wymagania dotyczące informacji o baterii

HAL Health 2.0 określa zestaw wymagań dotyczących interfejsu HAL, ale i testy VTS są egzekwowane w umiarkowanym stopniu. W Androidzie 11 pojawiły się nowe testy VTS, które wymuszają stosowanie następujące wymagania na urządzeniach uruchamianych z systemem Android 11 i nowsze:

  • Jednostkami prądu zmiennego i średniego baterii jest wartość w mikroA (μA).
  • Symbol chwilowego i średniego prądu baterii musi być prawidłowy. Więcej szczegółów:
    • bieżący == 0, gdy stan baterii to UNKNOWN
    • aktualnie > 0, gdy stan baterii to CHARGING
    • obecna <= 0, gdy stan baterii to NOT_CHARGING
    • bieżące < 0, gdy stan baterii to DISCHARGING
    • Nieegzekwowana, gdy stan baterii to FULL
  • Stan baterii musi być zgodny z tym, czy źródło zasilania jest – podłączono Więcej szczegółów:
    • stan baterii musi mieć wartość CHARGING, NOT_CHARGING lub FULL, jeśli i tylko wtedy, gdy jest podłączone źródło zasilania.
    • stan baterii musi wynosić DISCHARGING tylko wtedy, gdy źródło zasilania jest – rozłączono.

Jeśli korzystasz w swojej implementacji z interfejsu libbatterymonitor i przekazujesz wartości z interfejsów jądra, sprawdź, czy węzły sysfs zgłaszają prawidłowe wartości:

  • Upewnij się, że poziom naładowania baterii jest podawany z prawidłowym oznaczeniem i odpowiednimi jednostkami. Ten obejmuje następujące 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ą, jaki jest prąd wchodzący do baterii.
    • Wartości powinny być podane w mikroampery (μA).
  • Sprawdź, czy napięcie baterii jest podane w mikrowoltach (μV). Obejmuje to m.in.: te węzły sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Pamiętaj, że domyślna implementacja HAL dzieli voltage_now przez 1000 i podaje wartości w miliwoltach (mV). Zobacz @1.0::HealthInfo.

Więcej informacji: Klasa zasilacza – Linux.