Wdrażanie zdrowia 2.1

W Androidzie 11 cały kod healthd jest refaktoryzowany do libhealthloop i libhealth2impl , a następnie modyfikowany w celu implementacji HAL health@2.1. Te dwie biblioteki są połączone statycznie przez health@2.0-impl-2.1 , implementację przekazującą Health 2.1. Statycznie połączone biblioteki umożliwiają health@2.0-impl-2.1 wykonywanie tej samej pracy co healthd , takiej jak uruchamianie healthd_mainloop i odpytywanie. W init health@2.1-service rejestruje implementację interfejsu IHealth do hwservicemanager . W przypadku aktualizacji urządzeń z obrazem dostawcy systemu Android 8.x lub 9 oraz strukturą systemu Android 11 obraz dostawcy może nie zapewniać usługi health@2.1. Wsteczna zgodność z obrazami starych dostawców jest wymuszana przez harmonogram wycofywania oprogramowania .

Aby zapewnić kompatybilność wsteczną:

  1. healthd rejestruje IHealth w hwservicemanager , mimo że jest demonem systemowym. IHealth zostanie dodany do manifestu systemowego z nazwą instancji „backup”.
  2. Struktura i storaged komunikują się z healthd poprzez hwbinder zamiast binder .
  3. Kod frameworka i storaged został zmieniony, aby pobrać instancję „domyślną”, jeśli jest dostępna, a następnie „kopię zapasową”.
    • Kod klienta C++ wykorzystuje logikę zdefiniowaną w libhealthhalutils .
    • Kod klienta Java używa logiki zdefiniowanej w HealthServiceWrapper .
  4. Gdy IHealth/default stanie się powszechnie dostępny, a obrazy dostawców Androida 8.1 staną się przestarzałe, IHealth/backup i healthd mogą zostać uznane za przestarzałe. Aby uzyskać więcej informacji, zobacz Wycofywanie health@1.0 .

Zmienne kompilacji specyficzne dla płyty dla healthd

BOARD_PERIODIC_CHORES_INTERVAL_* to zmienne specyficzne dla płyty używane do budowania healthd . W ramach podziału systemu/dostawcy nie można definiować wartości specyficznych dla płyty dla modułów systemu. Wartości te były kiedyś zastępowane w przestarzałej funkcji healthd_board_init .

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

Wdrożenie usługi Zdrowie 2.1

Informacje na temat wdrażania usługi Health 2.1 można znaleźć pod adresem hardware/interfaces/health/2.1/README.md .

Klienci zdrowia

health@2.x ma następujących klientów:

  • ładowarka . Użycie kodu libbatterymonitor i healthd_common jest opakowane w health@2.0-impl .
  • powrót do zdrowia . Powiązanie z libbatterymonitor jest zawarte w health@2.0-impl . Wszystkie wywołania BatteryMonitor są zastępowane wywołaniami klasy implementacyjnej Health .
  • Menedżer baterii . BatteryManager.queryProperty(int id) był jedynym klientem IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty został dostarczony przez healthd i bezpośrednio odczytany /sys/class/power_supply .

    Ze względów bezpieczeństwa aplikacje nie mogą bezpośrednio wywoływać warstwy HAL kondycji. W systemie Android 9 i nowszych wersjach usługa segregatora IBatteryPropertiesRegistrar jest udostępniana przez BatteryService zamiast healthd . BatteryService deleguje wywołanie do warstwy HAL kondycji w celu pobrania żądanych informacji.

  • Serwis baterii . W systemie Android 9 i nowszych wersjach BatteryService używa HealthServiceWrapper do określenia, czy użyć domyślnego wystąpienia usługi kondycji od vendor , czy użyć zapasowego wystąpienia usługi kondycji od healthd . BatteryService następnie nasłuchuje zdarzeń zdrowotnych za pośrednictwem IHealth.registerCallback .

  • Przechowywany . W systemie Android 9 i nowszych wersjach storaged używa libhealthhalutils do określenia, czy użyć domyślnej instancji usługi kondycji od vendor , czy użyć zapasowej instancji usługi kondycji od healthd . storaged następnie nasłuchuje zdarzeń zdrowotnych za pośrednictwem IHealth.registerCallback i pobiera informacje o pamięci.

Zmiany w SELinuxie

Health@2.1 HAL zawiera następujące zmiany 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 dostawcy SELinux. 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 następujących interfejsów jądra w celu 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 HAL dotycząca kondycji specyficzna dla urządzenia, która używa libbatterymonitor , domyślnie uzyskuje dostęp do tych interfejsów jądra, chyba że zostanie to zastąpione w konstruktorze klasy implementacji kondycji.

Jeśli tych plików brakuje lub są one niedostępne z poziomu healthd lub usługi domyślnej (np. plik jest dowiązaniem symbolicznym do folderu specyficznego dla dostawcy, który odmawia dostępu z powodu źle skonfigurowanej polityki SELinux), mogą one nie działać poprawnie. Dlatego też mogą być konieczne dodatkowe zmiany w SELinux specyficzne dla dostawcy, nawet jeśli używana jest domyślna implementacja.

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łowym zachowaniom struktury wynikającym z brakujących interfejsów jądra, zaleca się wybranie CL 1398913 przed zbudowaniem usługi kondycji HAL 2.1.

Testowanie

Android 11 zawiera nowe testy VTS napisane specjalnie dla HAL health@2.1. Jeśli w manifeście urządzenia deklaruje się zdrowie@2.1 HAL, musi ono przejść odpowiednie testy VTS. Testy są pisane zarówno dla instancji domyślnej (aby upewnić się, że urządzenie poprawnie implementuje warstwę HAL), jak i instancji zapasowej (aby upewnić się, że healthd będzie nadal działać poprawnie, zanim zostanie usunięty).

Wymagania dotyczące informacji o baterii

HAL Health 2.0 określa zestaw wymagań dotyczących interfejsu HAL, ale odpowiednie testy VTS są stosunkowo swobodne w ich egzekwowaniu. W systemie Android 11 dodano nowe testy VTS w celu wymuszenia następujących wymagań na urządzeniach uruchamianych z systemem Android 11 i nowszym:

  • Jednostką chwilowego i średniego prądu akumulatora muszą być mikroampery (μA).
  • Znak chwilowego i średniego prądu akumulatora musi być prawidłowy. Konkretnie:
    • prąd == 0, gdy stan baterii jest UNKNOWN
    • prąd > 0, gdy stan akumulatora to CHARGING
    • prąd <= 0, gdy stan akumulatora to NOT_CHARGING
    • prąd < 0, gdy stan akumulatora to DISCHARGING
    • Nie wymuszane, gdy stan baterii jest FULL
  • Stan baterii musi być prawidłowy niezależnie od tego, czy źródło zasilania jest podłączone. Konkretnie:
    • stan baterii musi mieć wartość CHARGING , NOT_CHARGING lub FULL wtedy i tylko wtedy, gdy podłączone jest źródło zasilania;
    • stan akumulatora musi wynosić DISCHARGING wtedy i tylko wtedy, gdy źródło zasilania jest odłączone.

Jeśli używasz libbatterymonitor w swojej implementacji 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 akumulatora jest podawany z właściwym znakiem i jednostkami. Obejmuje to 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ą prąd przychodzący do akumulatora.
    • Wartości powinny być podawane w mikroamperach (µA).
  • Upewnij się, że napięcie akumulatora jest podawane w mikrowoltach (μV). Obejmuje to następujące węzły sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Należy zauważyć, że domyślna implementacja HAL dzieli voltage_now przez 1000 i podaje wartości w miliwoltach (mV). Zobacz @1.0::HealthInfo .

Aby uzyskać szczegółowe informacje, zobacz Klasa zasilacza systemu Linux .