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. Zgodność wsteczna z obrazami starych dostawców jest wymuszana przez harmonogram wycofywania .
Aby zapewnić kompatybilność wsteczną:
-
healthd
rejestrujeIHealth
whwservicemanager
mimo że jest demonem systemowym.IHealth
zostanie dodany do manifestu systemowego z nazwą instancji „backup”. - Struktura i
storaged
komunikują się zhealthd
poprzezhwbinder
zamiastbinder
. - 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
.
- Kod klienta C++ wykorzystuje logikę zdefiniowaną w
- 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
.
Wdróż usługę 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
ihealthd_common
jest opakowane whealth@2.0-impl
. - powrót do zdrowia. Powiązanie z
libbatterymonitor
jest zawarte whealth@2.0-impl
. Wszystkie wywołaniaBatteryMonitor
są zastępowane wywołaniami klasy implementacyjnejHealth
. Menedżer baterii.
BatteryManager.queryProperty(int id)
był jedynym klientemIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
został dostarczony przezhealthd
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 przezBatteryService
zamiasthealthd
.BatteryService
deleguje wywołanie do warstwy HAL kondycji w celu pobrania żądanych informacji.Serwis baterii. W systemie Android 9 i nowszych wersjach
BatteryService
używaHealthServiceWrapper
do określenia, czy użyć domyślnego wystąpienia usługi kondycji odvendor
, czy użyć zapasowego wystąpienia usługi kondycji odhealthd
.BatteryService
następnie nasłuchuje zdarzeń zdrowotnych za pośrednictwemIHealth.registerCallback
.Przechowywane. W systemie Android 9 i nowszych wersjach
storaged
używalibhealthhalutils
do określenia, czy użyć domyślnej instancji usługi kondycji odvendor
, czy użyć zapasowej instancji usługi kondycji odhealthd
.storaged
następnie nasłuchuje zdarzeń zdrowotnych poprzezIHealth.registerCallback
i pobiera informacje o magazynie.
Zmiany w SELinuxie
Health@2.1 HAL zawiera następujące zmiany SELinux na platformie:
- Dodaje
android.hardware.health@2.1-service
dofile_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 healthd
lub usługi domyślnej (na przykład plik jest dowiązaniem symbolicznym do folderu specyficznego dla dostawcy, który odmawia dostępu z powodu źle skonfigurowanej polityki SELinux), mogą nie działać poprawnie. Zatem 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 Health 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
- prąd == 0, gdy stan baterii jest
- 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
lubFULL
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.
- stan baterii musi mieć wartość
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 .