Android 9 zawiera android.hardware.health
HAL 2.0, główną aktualizację wersji health@1.0 HAL. Ten nowy HAL ma następujące zalety:
- Czystsza separacja pomiędzy frameworkiem i kodem dostawcy.
- Wycofuje niepotrzebnego demona
healthd
. - Większy stopień swobody dostosowywania dostawców w raportach z informacjami o stanie zdrowia.
- Więcej informacji o stanie urządzenia niż tylko o baterii.
Android 11 zawiera android.hardware.health
HAL 2.1, niewielką aktualizację 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 wysokich tonów w kodzie ładowania w trybie wyłączenia
- Lepsza obsługa 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 ładowarką
- Usuń nieużywany atrybut
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 uruchamiają się z systemem Android 9, ale planują aktualizację obrazu dostawcy do wersji 3 Target Framework Compatibility Matrix (wydanej w systemie Android 9), muszą usunąć istniejące implementacje HAL 1.0 i zapewnić HAL 2.x lub AIDL HAL.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, aby pomóc w implementacji HAL 2.0 i przejściu ze starej HAL 1.0.
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ą udostępniać warstwy HAL 1.0 lub 2.0) lub AIDL HAL. Urządzenia, które nie uruchamiają się z systemem Android 11, ale planują aktualizację obrazu dostawcy do wersji 5 Target Framework Compatibility Matrix (wydanej w systemie Android 11), muszą usunąć istniejące implementacje HAL 2.0 i zapewnić HAL 2.1 lub AIDL HAL. W przypadku urządzeń, które nie uruchamiają się z systemem Android 11 i nie planują aktualizacji obrazu dostawcy, zaleca się również zapewnienie warstwy HAL 2.1.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, aby pomóc w implementacji HAL 2.1 i przejściu ze starej HAL 1.0.
Urządzenia z Androidem 13 i 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 Target Framework Compatibility Matrix (wydanej w systemie Android 13), muszą usunąć istniejące implementacje HIDL HAL i zapewnić AIDL HAL. W przypadku urządzeń, które nie uruchamiają się z systemem Android 13 i nie planują aktualizacji obrazu dostawcy, zaleca się również zapewnienie AIDL HAL.
Urządzenia nie mogą zapewniać HIDL 1.0 HAL.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, aby pomóc w implementacji AIDL HAL i przejściu ze starych HIDL HAL.
Terminologia
- health@1.0 : skrót od
android.hardware.health@1.0
. Dotyczy Health HIDL HAL w wersji 1.0 wydanej w systemie Android 8.0. - health@2.0 : skrót od
android.hardware.health@2.0
. Dotyczy Health HIDL HAL w wersji 2.0 wydanej w systemie Android 9. - health@2.1 : skrót od
android.hardware.health@2.1
. Dotyczy Health 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 na Androida 13.
- ładowarka : plik wykonywalny działający w trybie wyłączenia, ładujący, wyświetlający animację ładowania telefonu.
- recovery : 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 dotyczące zdrowia 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 komponent 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ć inną libhealthd. BOARD
; w czasie kompilacji określa się, z jaką ładowarką, health@1.0-impl i odzyskiwaniem się łączą.
Dla innych trybów:
Rysunek 2. Kondycja w systemie Android 8.x, ładowanie w trybie wyłączenia i tryb odzyskiwania
- ładowarka statycznie łączy się z
libhealthd. BOARD
,libhealthd_charger
ilibbatterymonitor
. - recovery statycznie łączy się z
libhealthd. BOARD
ilibbatterymonitor
.
Zdrowie w Androidzie 9
W systemie Android 9 komponent Health działa zgodnie z poniższym diagramem:
Rysunek 3 . Zdrowie w Androidzie 9
Struktura próbuje pobrać usługę health@2.0 z hwservicemanager
. Jeśli się nie powiedzie, wywołuje health@1.0 (w systemie Android 8.x). Zachowano starszą ścieżkę kodu, aby obraz systemu Android 9 był zgodny z obrazem dostawcy Androida 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. Kondycja w systemie Android 9, ładowanie w trybie wyłączenia i tryb odzyskiwania
Zdrowie w Androidzie 11
W systemie Android 11 komponent zdrowia 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 kondycji 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 następujący uproszczony schemat dla różnych trybów:
Rysunek 5. Infrastruktura Health HAL 2.1
Zdrowie w Androidzie 13
W systemie Android 13 wprowadzono funkcję AIDL HAL. Komponent zdrowia działa zgodnie z poniższym diagramem:
Rysunek 6. Infrastruktura Health AIDL HAL
Interfejs HIDL HAL 2.0
Health@2.0 HAL zapewnia tę samą funkcjonalność frameworkowi, co stary demon healthd. Zapewnia także interfejsy API podobne do tych, które Healthd wcześniej udostępniał jako usługę segregatora (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
, aby zastąpić plikIBatteryPropertiesRegistrar.scheduleUpdate
-
IBatteryPropertiesRegistrar.getProperties
otrzymuje brzmienie:-
getChargeCounter
-
getCurrentNow
-
getCurrentAverage
-
getCapacity
-
getEnergyCounter
-
getChargeStatus
-
getHealthInfo
-
Ponadto IHealth
udostępnia następujące nowe interfejsy API do storaged
w celu pobierania informacji związanych z pamięcią masową specyficznych dla dostawcy:
-
getStorageInfo
-
getDiskStats
Nowa struktura @2.0::HealthInfo
jest zwracana poprzez wywołania zwrotne i getHealthInfo
. Ta struktura zawiera wszystkie informacje o stanie 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 masowej (informacje o urządzeniu pamięci masowej, statystyki dysku)
Aby uzyskać informacje na temat wdrażania usługi Health 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 akumulatorze.
Główny interfejs IHealth zapewnia następujące dodatkowe funkcje
-
getHealthConfig
: aby pobrać konfigurację tej warstwy HAL -
getHealthInfo_2_1
: niewielka aktualizacja wersji dogetHealthInfo
-
shouldKeepScreenOn
: aby określić, czy ekran powinien być włączony w trybie ładowarki
Ponadto implementacja @2.1::IHealth
jest wymagana do obsługi @2.1::IHealthInfoCallback
dla jego odziedziczonych funkcji registerCallback
i unregisterCallback
. Nowy interfejs wywołania zwrotnego zwraca klientowi informacje o kondycji przy użyciu funkcji healthInfoChanged_2_1
zamiast odziedziczonej funkcji healthInfoChanged
.
Nowa struktura @2.1::HealthInfo
jest zwracana poprzez wywołania zwrotne i getHealthInfo_2_1
. Ta struktura zawiera dodatkowe informacje o stanie urządzenia dostępne za pośrednictwem health@2.0 HAL, w tym:
- Poziom pojemności baterii
- Czas ładowania baterii do pełna (w sekundach)
- Projektowa pojemność akumulatora przy pełnym naładowaniu (w μAh)
Zobacz następujący diagram UML dla klas przydatnych w implementacji HAL kondycji:
Rysunek 7. Diagram UML kondycji HAL 2.1
Informacje na temat wdrażania usługi Health 2.1 można znaleźć w sekcji Implementowanie Health 2.1 .
Wersja interfejsu AIDL HAL 1
Zmiany w API
AIDL wersja 1 HAL obsługuje podobne API do HIDL 2.1 HAL. W porównaniu do interfejsu HIDL 2.1 w API zmieniono:
- Interfejsy API związane z ładowarkami wprowadzone w HIDL HAL 2.1 nie są przenoszone do AIDL HAL. Ponieważ funkcjonalność ładowania w trybie wyłączenia działa tylko na partycji
/vendor
, interfejsy API w interfejsie dostawcy nie są konieczne. Aby prawidłowo wdrożyć ładowanie w trybie wyłączenia, zobacz ładowarkę poniżej. - Typ
StorageAttribute
i powiązane pola są usuwane, ponieważ są nieużywane. - Do
HealthInfo
dodanochargerDockOnline
, która umożliwia ładowanie stacji dokującej.
Realizacja
Zobacz następujący diagram UML dla klas przydatnych w implementacji HAL kondycji:
Rysunek 8. Diagram UML kondycji AIDL HAL
Informacje na temat implementowania usługi AIDL dotyczące kondycji można znaleźć w sekcji Implementowanie HAL Health AIDL .
Powrót do zdrowia
Android 13 obsługuje segregator podczas odzyskiwania. Zainstalowanie usługi Health AIDL do odzyskiwania umożliwia jej uruchomienie w trybie odzyskiwania.
Informacje na temat instalowania usługi kondycji AIDL w celu odzyskiwania można znaleźć w następujących sekcjach:
Ł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ą one ładowanie w trybie wyłączenia, plik binarny usługi HAL musi obsługiwać tryb ładowarki. Aby to zrobić, zobacz wdrażanie ładowarki .
Właściwości układu ładowarki
Właściwości ro.charger.*
nie są już czytelne dla pliku binarnego charger
w /vendor
. Jeśli w Twoim urządzeniu ustawiono którąkolwiek z właściwości systemowych ro.charger.*
, zapoznaj się z właściwościami systemowymi ładowarki .