Android 9 zawiera android.hardware.health
HAL 2.0, główną aktualizację z health@1.0 HAL. Ten nowy HAL ma następujące zalety:
- Czystsza separacja między frameworkiem a kodem dostawcy.
-
healthd
się niepotrzebnego demona w dobrej kondycji. - Większy stopień swobody dostosowywania dostawcy w raportach dotyczących informacji o stanie zdrowia.
- Więcej informacji o stanie urządzenia niż tylko bateria.
Android 11 zawiera android.hardware.health
HAL 2.1, pomniejsze uaktualnienie wersji health@2.0 HAL. Ten nowy HAL ma następujące zalety:
- Łatwiejsze do wdrożenia
- Lepsza zgodność z istniejącymi interfejsami API HAL 2.0
- Lepsza separacja tonów wysokich w kodzie ładowania w trybie wyłączenia
- Lepsze wsparcie dla struktury wskazującej stan baterii urządzenia
Android 13 zawiera android.hardware.health
AIDL HAL, konwersję z health@2.1 HAL. Ten nowy HAL ma następujące zalety:
- Usuń nieużywane interfejsy API związane z ładowarkami
- Usuń nieużywany
StorageAttribute
i powiązane pola - Obsługa ładowania stacji dokującej.
Wymagania
Urządzenia z systemem Android 9 i Android 10
Urządzenia uruchamiane z systemem Android 9 muszą zapewniać warstwę HAL 2.x (i nie mogą udostępniać warstwy HAL 1.0) lub AIDL HAL. Urządzenia, które nie są uruchamiane z systemem Android 9, ale planują aktualizację obrazu dostawcy do wersji Target Framework Compatibility Matrix w wersji 3 (wydanej w systemie Android 9), muszą usunąć istniejące implementacje HAL 1.0 i zapewnić 2.x HAL lub AIDL HAL.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, aby pomóc w implementacji 2.0 HAL i przejściu ze starej 1.0 HAL.
Urządzenia z systemem Android 11 i Android 12
Urządzenia uruchamiane z systemem Android 11 muszą zapewniać warstwę HAL 2,1 (i nie mogą zapewniać warstwy HAL 1,0 ani 2,0) ani warstwy AIDL HAL. Urządzenia, które nie są uruchamiane z systemem Android 11, ale planują aktualizację obrazu dostawcy do Target Framework Compatibility Matrix w wersji 5 (wydanej w systemie Android 11), muszą usunąć istniejące implementacje HAL 2,0 i zapewnić 2,1 HAL lub AIDL HAL. Urządzenia, które nie uruchamiają się z systemem Android 11 i nie planują aktualizacji obrazu dostawcy, są również zalecane w celu zapewnienia warstwy HAL 2.1.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, aby pomóc w implementacji warstwy HAL 2.1 i przejściu ze starej warstwy 1.0 HAL.
Urządzenia z systemem Android 13 lub nowszym
Urządzenia uruchamiane z systemem Android 13 muszą zapewniać AIDL HAL (i nie mogą zapewniać HIDL HAL). Urządzenia, które nie uruchamiają się z systemem Android 13, ale planują aktualizację obrazu dostawcy do wersji 7 (wydanej w systemie Android 13), muszą usunąć istniejące implementacje HIDL HAL i udostępnić AIDL HAL. Urządzenia, które nie uruchamiają się z systemem Android 13 i nie planują aktualizacji obrazu dostawcy, są również zalecane, aby zapewnić AIDL HAL.
Urządzenia nie mogą dostarczać HIDL 1.0 HAL.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych w celu ułatwienia implementacji warstwy HAL AIDL i przejścia ze starych warstw HAL HIDL.
Terminologia
- health@1.0 : skrót od
android.hardware.health@1.0
. Odnosi się do zdrowia HIDL HAL w wersji 1.0 wydanej w systemie Android 8.0. - health@2.0 : skrót od
android.hardware.health@2.0
. Odnosi się do zdrowia HIDL HAL w wersji 2.0 wydanej w systemie Android 9. - health@2.1 : skrót od
android.hardware.health@2.1
. Odnosi się do zdrowia HIDL HAL w wersji 2.1 wydanej w systemie Android 11. - zdrowie AIDL HAL : skrót od
android.hardware.health
.- Wersja 1 została wydana w systemie Android 13.
- ładowarka : plik wykonywalny działający w trybie wyłączenia, który wyświetla animację ładowania telefonu.
- odzyskiwanie : plik wykonywalny działający w trybie odzyskiwania, który musi pobrać informacje o baterii.
- healthd : starszy demon działający w systemie Android, który pobiera informacje związane ze zdrowiem i udostępnia je frameworkowi.
- storaged : demon działający w systemie Android, który pobiera informacje o pamięci i udostępnia je frameworkowi.
Zdrowie w Androidzie 8.x
W systemie Android 8.x składnik Health działa zgodnie z poniższym diagramem:
Rysunek 1 . Zdrowie w Androidzie 8.x
Na tym schemacie:
- Jedno (1) wywołanie bindera i jedno (1) wywołanie hwbinder są używane przez platformę do komunikacji ze sprzętem.
-
healthd
statycznie łączy się zlibhealthd_android
,libbatterymonitor
ilibbatteryservice
. - health@1.0-impl statycznie łączy się z
libhealthd. BOARD
.
Każda tablica może dostosować inny libhealthd. BOARD
; w czasie kompilacji jest określane, z czym łączy się ładowarka, zdrowie@1.0-impl i odzyskiwanie.
Dla innych trybów:
Rysunek 2. Zdrowie w systemie Android 8.x, ładowanie w trybie wyłączenia i tryb odzyskiwania
- ładowarka statycznie łączy się z
libhealthd. BOARD
,libhealthd_charger
ilibbatterymonitor
. - odzyskiwanie statycznie łączy się z
libhealthd. BOARD
ilibbatterymonitor
.
Zdrowie w Androidzie 9
W systemie Android 9 składnik Health działa zgodnie z poniższym diagramem:
Rysunek 3 . Zdrowie w Androidzie 9
Framework próbuje pobrać usługę health@2.0 z hwservicemanager
. Jeśli się nie powiedzie, wywołuje health@1.0 (w Androidzie 8.x). Starsza ścieżka kodu jest zachowywana, więc obraz systemu Android 9 jest zgodny z obrazem dostawcy systemu Android 8.x. Struktura nie pobiera informacji z obu warstw HAL, ponieważ na urządzeniu może istnieć tylko jedna wersja usługi (1.0 lub 2.0).
Dla innych trybów:
Rysunek 4. Zdrowie w systemie Android 9, ładowanie w trybie wyłączenia i tryb odzyskiwania
Zdrowie w Androidzie 11
W systemie Android 11 składnik Health działa zgodnie z poniższym diagramem:
[system]
| getService()
V
[health@2.1-service]
| getService(stub=true)
V
[ health@2.0-impl-2.1-<device>.so ]
| | (device-dependent linkage)
V V
+---------Helper libs for impl--------+ [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl) ] |
| [libbatterymonitor (battery) ] |
+-------------------------------------+
Jeśli implementacja Health 2.1 nie istnieje, system powraca do starszej ścieżki kodu, jak opisano w poprzednich sekcjach
Dla innych trybów:
[ charger ]
| getService() | (legacy code path)
V +-------------------------------------------------+
[health@2.1-service] |
| getService(stub=true) |
V |
[ health@2.0-impl-2.1-<device>.so ] |
| | (device-dependent linkage) |
V V |
+---------Helper libs for impl--------+ [libhealthd.device] |
| [libhealthloop (uevent, wakealarm)] | |
| [libhealth2impl (IHealth impl) ] | <---------------------------------+
| [libbatterymonitor (battery) ] |
+-------------------------------------+
[recovery]
| getService() w/o hwservicemanager
V
[ health@2.0-impl-2.1-<device>.so ]
| | (device-dependent linkage)
V V
+---------Helper libs for impl--------+ [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl) ] |
| [libbatterymonitor (battery) ] |
+-------------------------------------+
Zobacz poniższy uproszczony schemat dla różnych trybów:
Rysunek 5. Infrastruktura HAL 2.1 dla zdrowia
Zdrowie w Androidzie 13
W systemie Android 13 wprowadzono zdrowie AIDL HAL. Składnik zdrowia działa zgodnie z poniższym diagramem:
Rysunek 6. Infrastruktura Health AIDL HAL
HIDL HAL interfejs 2.0
HAL health@2.0 zapewnia tę samą funkcjonalność frameworka, co stary demon w dobrej kondycji. Zapewnia również interfejsy API, które są podobne do tych, które były wcześniej zapewniane jako usługa spinacza (tj. IBatteryPropertiesRegistrar ).
Główny interfejs, IHealth , udostępnia następujące funkcje:
-
registerCallback
, aby zastąpićIBatteryPropertiesRegistrar.registerListener
-
unregisterCallback
, aby zastąpićIBatteryPropertiesRegistrar.unregisterListener
-
update
, w celu zastąpieniaIBatteryPropertiesRegistrar.scheduleUpdate
-
IBatteryPropertiesRegistrar.getProperties
otrzymują brzmienie:-
getChargeCounter
-
getCurrentNow
-
getCurrentAverage
-
getCapacity
-
getEnergyCounter
-
getChargeStatus
-
getHealthInfo
-
Ponadto IHealth
udostępnia następujące nowe interfejsy API do storaged
w celu pobierania informacji dotyczących pamięci masowej specyficznych dla dostawcy:
-
getStorageInfo
-
getDiskStats
Nowa struktura @2.0::HealthInfo
jest zwracana przez wywołania zwrotne i getHealthInfo
. Ta struktura zawiera wszystkie informacje o kondycji urządzenia dostępne za pośrednictwem health@2.0 HAL, w tym:
- Informacje o ładowaniu (AC/USB/bezprzewodowe, prąd, napięcie itp.)
- Informacje o baterii (obecność, poziom baterii, prąd, napięcie, ładunek, technologia itp.)
- Informacje o pamięci (informacje o urządzeniu pamięci masowej, statystyki dysku)
Aby uzyskać informacje na temat implementowania usługi Health service 2.0, zobacz Implementing Health 2.0 .
Interfejs HIDL HAL 2.1
Health@2.1 HAL obsługuje ładowanie w trybie wyłączenia i dostarcza więcej informacji o baterii.
Główny interfejs, IHealth , zapewnia następujące dodatkowe funkcje:
-
getHealthConfig
: do pobrania konfiguracji tej warstwy HAL -
getHealthInfo_2_1
: aktualizacja wersji pomocniczej dogetHealthInfo
-
shouldKeepScreenOn
: aby określić, czy ekran powinien być utrzymywany w trybie ładowarki
Ponadto implementacja @2.1::IHealth
jest wymagana do obsługi @2.1::IHealthInfoCallback
dla dziedziczonych funkcji registerCallback
i unregisterCallback
. Nowy interfejs wywołania zwrotnego zwraca klientowi informacje o kondycji przy użyciu jego funkcji healthInfoChanged_2_1
zamiast dziedziczonej funkcji healthInfoChanged
.
Nowa struktura @2.1::HealthInfo
jest zwracana przez wywołania zwrotne i getHealthInfo_2_1
. Ta struktura zawiera dodatkowe informacje o kondycji urządzenia dostępne za pośrednictwem Health@2.0 HAL, w tym:
- Poziom naładowania baterii
- Czas ładowania akumulatora do pełnego teraz (w sekundach)
- Pojemność projektowa pełnego naładowania akumulatora (w μAh)
Zapoznaj się z poniższym diagramem UML, aby zapoznać się z klasami przydatnymi w implementacji HAL kondycji:
Rysunek 7. Health HAL 2.1 Diagram UML
Aby uzyskać informacje na temat wdrażania usługi Health service 2.1, zobacz Implementing Health 2.1 .
Interfejs AIDL HAL wersja 1
Zmiany API
AIDL wersja 1 HAL obsługuje podobne interfejsy API do HIDL 2.1 HAL. W porównaniu z interfejsem HIDL 2.1 w API zmieniono:
- Interfejsy API związane z ładowarką wprowadzone w HIDL HAL 2.1 nie są przenoszone do AIDL HAL. Ponieważ funkcja ładowania w trybie wyłączenia działa tylko na partycji
/vendor
, interfejsy API w interfejsie dostawcy nie są konieczne. Aby prawidłowo zaimplementować ładowanie w trybie wyłączenia, patrz ładowarka poniżej. - Typ
StorageAttribute
i powiązane pola są usuwane, ponieważ nie są używane. -
chargerDockOnline
jest dodawany doHealthInfo
w celu obsługi ładowania stacji dokującej.
Realizacja
Zapoznaj się z poniższym diagramem UML, aby zapoznać się z klasami przydatnymi w implementacji HAL kondycji:
Rysunek 8. Health AIDL HAL UML diagram
Aby uzyskać informacje na temat implementowania usługi AIDL kondycji, zobacz Implementowanie warstwy AIDL kondycji .
Powrót do zdrowia
Android 13 obsługuje segregator w odzyskiwaniu. Zainstalowanie usługi Health AIDL do odzyskiwania umożliwia jej działanie w trybie odzyskiwania.
Aby uzyskać informacje na temat instalowania usługi AIDL kondycji do odzyskiwania, zobacz następujące informacje:
Ładowarka
Funkcjonalność ładowania w trybie wyłączenia została przeniesiona z /system
do /vendor
. W przypadku urządzeń uruchamianych z systemem Android 13, jeśli obsługują ładowanie w trybie wyłączenia, plik binarny usługi HAL musi obsługiwać tryb ładowarki. Aby to zrobić, zapoznaj się z implementacją ładowarki .
Właściwości systemu ładowarki
Właściwości ro.charger.*
nie są już odczytywane przez plik binarny charger
w /vendor
. Jeśli Twoje urządzenie ma ustawioną dowolną z właściwości systemu ro.charger.*
, zapoznaj się z właściwościami systemu dotyczącymi ładowarki .