Android 9 zawiera android.hardware.health
HAL 2.0,
uaktualnienie wersji głównej z HAL Health@1.0. Nowa HAL ma te
zalety:
- Bardziej przejrzyste oddzielenie kodu platformy od kodu dostawcy.
- Wycofuje zbędny demon
healthd
. - Większa swoboda w zakresie dostosowywania informacji dotyczących zdrowia przez dostawcę. raportów.
- Więcej informacji o stanie urządzenia niż tylko bateria.
Android 11 zawiera android.hardware.health
HAL 2.1,
uaktualnienie wersji podrzędnej z HAL Health@2.0. Nowa HAL ma te
zalety:
- Łatwiejsze wdrożenie
- Lepsza zgodność z istniejącymi interfejsami API HAL 2.0
- Lepsza separacja wysokich tonów w przypadku kodu ładowania w trybie wyłączonym
- Lepsza obsługa platformy w celu wskazywania stanu baterii urządzenie
Android 13 zawiera android.hardware.health
AIDL HAL,
a konwersja z Health@2.1 HAL. Nowa HAL ma te
zalety:
- Usuń nieużywane interfejsy API związane z ładowarkami
- Usuń nieużywane pola
StorageAttribute
i powiązane pola - Obsługa ładowania stacji dokującej.
Wymagania
Urządzenia z Androidem 9 i 10
Urządzenia wprowadzane na rynek z Androidem 9 muszą obsługiwać format 2.x HAL (i nie może zawierać HAL 1.0) ani AIDL HAL. Urządzenia nie uruchamiają się z Androidem 9, ale planujemy zaktualizować zdjęcie dostawcy do docelowej macierzy zgodności platformy w wersji 3 (opublikowanej w Androidzie 9) musi usunąć istniejące implementacje HAL w wersji 1.0 oraz udostępniać HAL 2.x lub AIDL HAL.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, by pomóc Ci we wdrożeniu wersji 2.0 HAL i przejście ze starej wersji HAL 1.0.
Urządzenia z Androidem 11 i 12
Urządzenia z Androidem 11 muszą obsługiwać wersję 2.1 HAL (i nie może zawierać HAL w wersji 1.0 ani 2.0) ani AIDL. Urządzenia nie wprowadza na rynek Androida 11, ale planujemy zaktualizować obrazu dostawcy do macierzy zgodności platformy docelowej w wersji 5 (opublikowanej w Android 11) musi usunąć istniejącą wersję HAL 2.0 i udostępniać HAL 2.1 lub AIDL. Urządzenia nie uruchamiają się z Androidem 11 i nie planujesz aktualizować dostawcy zalecane są też obrazy w przypadku kodu HAL 2.1.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, by pomóc Ci we wdrożeniu 2.1 HAL i przejście ze starej wersji HAL 1.0.
Urządzenia z Androidem 13 lub nowszym
Urządzenia uruchamiane z Androidem 13 muszą obsługiwać AIDL HAL (i nie może zawierać HIDL HAL). Urządzenia, na których nie uruchomiono Androida 13, ale planowane jest zaktualizowanie obrazu dostawcy do wersji docelowej Macierz zgodności platformy w wersji 7 (opublikowana w Androidzie 13) musi usuwać istniejące implementacje HIDL HAL oraz udostępnienie interfejsu AIDL HAL. Urządzenia, które nie mają Androida 13 i nie planują aktualizacji obrazu dostawcy, również zostaną zalecamy podanie wartości HAL AIDL.
Urządzenia nie mogą udostępniać HAL HIDL 1.0.
AOSP zawiera wiele bibliotek pomocniczych zaprojektowanych, aby pomóc w implementacji AIDL HAL i przejście ze starych baz HIDL.
Terminologia
- health@1.0: skrót
android.hardware.health@1.0
. Odnosi się do zdrowie HIDL HAL w wersji 1.0 opublikowane na Androidzie 8.0, - health@2.0: skrót
android.hardware.health@2.0
. Odnosi się do zdrowie HIDL HAL w wersji 2.0 na Androidzie 9. - health@2.1: skrót
android.hardware.health@2.1
. Odnosi się do zdrowie HIDL HAL w wersji 2.1 opublikowane na Androidzie 11. - Health AIDL HAL: skrót od
android.hardware.health
.- Wersja 1 zostaje udostępniona na Androidzie 13.
- charger: plik wykonywalny działający w trybie ładowania wyłączonego, który wyświetla animacja ładowania telefonu.
- recovery: plik wykonywalny działający w trybie przywracania, który musi odzyskać baterię. i informacjami o nich.
- healthd: starszy demon działający na Androidzie, który pobiera informacje o stanie zdrowia. informacji i traktowania ich jako podstaw.
- storaged: demon działający na Androidzie, który pobiera informacje o miejscu na dane. i przekształca je w ramy.
Zdrowie na Androidzie 8.x
W Androidzie 8.x komponent stanu działa w sposób opisany na tym schemacie:
Rysunek 1. Zdrowie na Androidzie 8.x
Na tym diagramie:
- Platforma używa jednego (1) wywołania Binder i jednego (1) wywołania hwbinder do komunikacją ze sprzętem.
healthd
tworzy statyczne linki do tych źródeł:libhealthd_android
,libbatterymonitor
ilibbatteryservice
- Health@1.0-impl zawiera statyczne linki do
libhealthd.BOARD
Na każdej tablicy można dostosować inny element libhealthd.BOARD
.
Jest to określane podczas kompilacji, które ładowarki, zdrowie@1.0-impl i link odzyskiwania
do.
W przypadku innych trybów:
Rysunek 2. Health w Androidzie 8.x, ładowanie w trybie wyłączonym i tryb przywracania.
- ładowarka łączy się statycznie z siecią
libhealthd.BOARD
,libhealthd_charger
ilibbatterymonitor
. - jest statycznie powiązany z narzędziami
libhealthd.BOARD
ilibbatterymonitor
Zdrowie na Androidzie 9
Na Androidzie 9 komponent stanu działa w tak szczegółowy sposób na tym diagramie:
Rysunek 3. Zdrowie na Androidzie 9
Platforma próbuje pobrać usługę Health@2.0 z hwservicemanager
.
W przypadku niepowodzenia wywołuje metodę Health@1.0 (w Androidzie 8.x). Ścieżka kodu starszego typu to
aby obraz systemu Android 9 był zgodny z
z obrazem dostawcy Androida 8.x. Platforma nie pobiera informacji z
obie HAL, ponieważ na urządzeniu może być zainstalowana tylko jedna wersja usługi (1.0 lub 2.0).
W przypadku innych trybów:
Rysunek 4. Health w Androidzie 9, ładowanie w trybie wyłączonym i tryb przywracania.
Zdrowie w Androidzie 11
W Androidzie 11 komponent dotyczący zdrowia działa w szczegółowy sposób na tym diagramie:
[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 ścieżka starszej wersji kodu zgodnie z opisem w poprzednich sekcjach
W przypadku 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 ten uproszczony diagram dla różnych trybów:
Rysunek 5. Infrastruktura HAL 2.1 w zakresie zdrowia.
Zdrowie na Androidzie 13
W Androidzie 13 wprowadzono interfejs AIDL HAL dotyczący stanu zdrowia. działa zgodnie z tym diagramem:
Rysunek 6. Infrastruktura HAL AIDL.
Interfejs HIDL HAL 2.0
HAL Health@2.0 zapewnia te same funkcje co poprzednia platforma i zdrowym demonem. Udostępnia też interfejsy API podobne do tych dawniej świadczona jako usługa spowalniająca (tj. IBatteryWłaściwościRegistrar).
Główny interfejs iHealth , udostępnia te funkcje:
registerCallback
, do zastąpieniaIBatteryPropertiesRegistrar.registerListener
unregisterCallback
, do zastąpieniaIBatteryPropertiesRegistrar.unregisterListener
update
, aby zastąpićIBatteryPropertiesRegistrar.scheduleUpdate
- Pole
IBatteryPropertiesRegistrar.getProperties
zostało zastąpione tym:getChargeCounter
getCurrentNow
getCurrentAverage
getCapacity
getEnergyCounter
getChargeStatus
getHealthInfo
Dodatkowo IHealth
udostępnia następujące nowe interfejsy API dla storaged
, aby:
pobieranie informacji związanych z pamięcią specyficznych dla dostawcy:
getStorageInfo
getDiskStats
Wywołanie zwrotne i getHealthInfo
zwracają nową strukturę (@2.0::HealthInfo
).
Ten struct zawiera wszystkie informacje o stanie urządzeń dostępne na stronie Health@2.0
HAL, w tym:
- Informacje dotyczące ładowania (prąd elektryczny/USB/bezprzewodowy, prąd, napięcie itp.)
- informacje o baterii (obecność, poziom baterii, natężenie, napięcie, poziom naładowania, technologia itp.)
- Informacje o pamięci (informacje o urządzeniu pamięci masowej, statystyki dysku)
Aby uzyskać informacje na temat wdrażania usługi Health 2.0, zapoznaj się z artykułem Wdrażanie Health 2.0.
Interfejs HIDL HAL 2.1
Health@2.1 HAL obsługuje ładowanie w trybie wyłączonym i zapewnia więcej informacji co do baterii.
Główny interfejs IHealth udostępnia następujące funkcje dodatkowe
getHealthConfig
: pobieranie konfiguracji tej HALgetHealthInfo_2_1
: uaktualnienie wersji podrzędnej do wersjigetHealthInfo
shouldKeepScreenOn
: określa, czy ekran powinien być pozostawiony włączony tryb ładowania
Ponadto implementacja @2.1::IHealth
jest wymagana do obsługi
@2.1::IHealthInfoCallback
dla dziedziczonych reguł: registerCallback
i
unregisterCallback
. Nowy interfejs wywołania zwrotnego zwraca stan
do informacji klientowi za pomocą funkcji healthInfoChanged_2_1
zamiast
odziedziczonej funkcji healthInfoChanged
.
przez wywołania zwrotne zwracany jest nowy element struct (@2.1::HealthInfo
).
getHealthInfo_2_1
Ten element struct zawiera dodatkowe informacje o stanie urządzenia
dostępne w Health@2.0 HAL, w tym:
- Poziom naładowania baterii
- Czas pełnego naładowania baterii (w sekundach)
- Pojemność całkowita naładowana do pełnego naładowania (w μAh)
Zapoznaj się z tym diagramem UML dla klas przydatnych w implementacji HAL stanu:
Rysunek 7. Diagram UML HAL 2.1 w zakresie zdrowia.
Informacje o wdrażaniu usługi Health 2.1 znajdziesz tutaj Wdrażanie Health 2.1.
Interfejs AIDL HAL w wersji 1
Zmiany w interfejsie API
AIDL w wersji 1 HAL obsługuje podobne interfejsy API do HIDL 2.1 HAL. W porównaniu z w interfejsie HIDL 2.1, zostają w nim zmienione następujące zmiany:
- Interfejsy API związane z ładowarkami wprowadzone w HIDL HAL 2.1 nie są przenoszone do AIDL
HAL. Ponieważ ładowanie w trybie wyłączonym działa tylko na
/vendor
, interfejsy API w interfejsie dostawcy nie są konieczne. Do prawidłowo wdrożyć ładowanie w trybie wyłączonym, patrz ładowarka poniżej. - Typ
StorageAttribute
i powiązane pola zostały usunięte, ponieważ są nieużywane. - Urządzenie
chargerDockOnline
zostało dodane do urządzeniaHealthInfo
, aby umożliwić ładowanie ze stacji dokującej.
Implementacja
Zapoznaj się z tym diagramem UML dla klas przydatnych w implementacji HAL stanu:
Rysunek 8. Diagram Health AIDL HAL UML.
Informacje na temat wdrażania usługi AIDL dla zdrowia znajdziesz w Wdrażanie HAL Health AIDL.
Odzyskanie
Android 13 obsługuje tworzenie powiązania podczas przywracania. Instalowanie programu Usługa Health AIDL do przywracania umożliwia działanie w trybie przywracania.
Informacje na temat instalowania usługi AIDL stanu w procesie przywracania znajdziesz w :
Ładowarka
Funkcjonalność ładowania w trybie wyłączonym została przeniesiona z /system
do /vendor
. Dla:
urządzeń z Androidem 13, jeśli obsługują
ładowania w trybie wyłączonym, plik binarny usługi HAL musi obsługiwać tryb ładowarki. Aby to zrobić:
patrz
wdrożyć ładowarkę.
Właściwości systemu ładowarki
Właściwości ro.charger.*
nie są już czytelne dla pliku binarnego charger
w
/vendor
Jeśli na urządzeniu masz ustawioną dowolną z właściwości systemowych ro.charger.*
,
patrz
właściwości systemowe ładowarki.