Stan systemu Android

Android 9 zawiera android.hardware.health HAL 2.0, główną wersję uaktualnienia Health@1.0 HAL. Nowa HAL ma te zalety:

• Lepsze oddzielenie ramy od kodu dostawcy.
• Wycofuje zbędny demon healthd.
• Większa swoboda dostosowywania raportów z informacjami o zdrowiu przez dostawców.
• więcej informacji o stanie urządzenia niż tylko o baterii.

Android 11 zawiera android.hardware.health HAL 2.1, co jest drobną aktualizacją interfejsu HAL health@2.0. Nowa wersja HAL ma te zalety:

• Łatwiejsza implementacja
• Lepsze dopasowanie do istniejących interfejsów HAL 2.0
• Lepsze oddzielenie Treble w kodzie ładowania w trybie offline
• lepsza obsługa platformy, która wskazuje stan baterii urządzenia;

Android 13 zawiera interfejs android.hardware.health AIDL HAL, który jest konwersją interfejsu health@2.1 HAL. Nowa HAL ma te zalety:

• Usuwanie nieużywanych interfejsów API związanych z ładowarkami
• Usuwanie nieużywanych pól StorageAttribute i powiązanych z nimi pól
• Obsługa ładowania na stacji dokującej.

Wymagania

Urządzenia z Androidem 9 i 10

Urządzenia z Androidem 9 muszą mieć interfejs HAL 2.x (nie można używać interfejsu HAL 1.0) lub interfejs AIDL HAL. Urządzenia, które nie są uruchamiane z Androidem 9, ale planują zaktualizować obraz dostawcy do wersji 3 macierzy zgodności platformy docelowej (wydanej w Androidzie 9), muszą usunąć istniejące implementacje interfejsu HAL 1.0 i zastosować interfejs HAL 2.x lub interfejs HAL AIDL.

AOSP zawiera wiele bibliotek pomocniczych, które ułatwiają implementację interfejsu HAL 2.0 i przejście ze starego interfejsu HAL 1.0.

Urządzenia z Androidem 11 i Androidem 12

Urządzenia z Androidem 11 muszą mieć interfejs HAL 2.1 (nie można używać interfejsu HAL 1.0 ani 2.0) lub interfejs AIDL HAL. Urządzenia, które nie są jeszcze dostępne w Androidzie 11, ale mają zostać zaktualizowane do wersji 5 z tablicy zgodności z Target Framework (opublikowanej w Androidzie 11), muszą usunąć istniejące implementacje interfejsu HAL 2.0 i zastosować interfejs HAL 2.1 lub interfejs HAL AIDL. Zaleca się też, aby urządzenia, które nie uruchamiają Androida 11 i nie planują aktualizować obrazu dostawcy, zawierały HAL 2.1.

AOSP zawiera wiele bibliotek pomocniczych, które ułatwiają implementację interfejsu HAL 2.1 i przejście ze starego interfejsu HAL 1.0.

Urządzenia z Androidem 13 lub nowszym

Urządzenia wprowadzane na rynek z Androidem 13 muszą zawierać kod HAL AIDL (i nie mogą udostępniać HAL HIDL). Urządzenia, które nie są uruchamiane z Androidem 13, ale planują zaktualizować obraz dostawcy do wersji docelowej w ramach wersji 7 macierzy zgodności frameworku (wydane w Androidzie 13), muszą usunąć istniejące implementacje interfejsu HIDL HAL oraz udostępnić interfejs AIDL HAL. W przypadku urządzeń, które nie mają Androida 13 i nie planują aktualizować obrazu dostawcy, zalecamy również stosowanie wartości HAL AIDL.

Urządzenia nie mogą udostępniać interfejsu HIDL 1.0.

AOSP zawiera wiele bibliotek pomocniczych, które ułatwiają implementację interfejsu AIDL HAL i przejście ze starych interfejsów HIDL HAL.

Terminologia

• health@1.0: skrót od android.hardware.health@1.0. Odnosi się do interfejsu HIDL HAL dla zdrowia w wersji 1.0, który został wydany w Androidzie 8.0.
• health@2.0: skrót od android.hardware.health@2.0. Odnosi się do interfejsu HIDL HAL dla zdrowia w wersji 2.0, który został wydany w Androidzie 9.
• health@2.1: skrót od android.hardware.health@2.1. Odnosi się do stanu HAL HIDL w wersji 2.1 wydanej w Androidzie 11.
• health AIDL HAL: skrót od android.hardware.health.
  • Wersja 1 została wydana w Androidzie 13.
• charger: plik wykonywalny działający w trybie ładowania w trybie wyłączenia, który wyświetla 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 Androidzie, który pobiera informacje dotyczące zdrowia i przekazuje je do frameworku.
• storaged: demon działający na Androidzie, który pobiera informacje o pamięci i przekazuje je do frameworku.

Zdrowie na Androidzie 8.x

W Androidzie 8.x komponent stanu działa zgodnie z diagramem poniżej:

Rysunek 1 Health w Androidzie 8.x.

Na tym diagramie:

• Do komunikacji z sprzętem framework używa 1 wywołania binder i 1 wywołania hwbinder.
• healthd jest połączony statycznie z usługami libhealthd_android, libbatterymonitor i libbatteryservice.
• health@1.0-impl zawiera linki statyczne do libhealthd.BOARD.

Każda płyta może mieć inny libhealthd.BOARD. W czasie kompilacji określa się, jakie wartości mają mieć charger, health@1.0-impl i recovery link.

W przypadku innych trybów:

Rysunek 2. Stan w Androidzie 8.x, ładowanie w trybie wyłączenia i tryb przywracania.

• ładowarka jest statycznie połączona z libhealthd.BOARD, libhealthd_charger i libbatterymonitor.
• recovery jest statycznie powiązany z libhealthd.BOARD i libbatterymonitor.

Zdrowie w Androidzie 9

W Androidzie 9 komponent stanu zdrowia działa zgodnie z tym schematem:

Rysunek 3. Health w Androidzie 9.

Platforma próbuje pobrać usługę health@2.0 z hwservicemanager. Jeśli się nie uda, wywołuje health@1.0 (w Androidzie 8.x). Stary kod jest zachowany, aby obraz systemu Android 9 był zgodny z obrazem dostawcy Androida 8.x. Platforma nie pobiera informacji z obu list HAL, ponieważ na urządzeniu może istnieć tylko jedna wersja usługi (1.0 lub 2.0).

Uwaga: procesy i biblioteki powiązane ze starszą wersją kodu będą zachowane do czasu wycofania health@1.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 tak, jak pokazano na poniższym 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 korzysta z ścieżki kodu starszej wersji 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 w Androidzie 13

W Androidzie 13 wprowadzono interfejs AIDL HAL dotyczący stanu zdrowia. Komponent stanu działa tak jak na tym diagramie:

Rysunek 6. Infrastruktura Health AIDL HAL.

Interfejs HIDL HAL 2.0

HAL Health@2.0 udostępnia te same funkcje co poprzedni demon o sprawnym stanie. Udostępnia on też interfejsy API podobne do tych, które healthd wcześniej udostępniał jako usługa binder (np. IBatteryPropertiesRegistrar).

Główny interfejs IHealth udostępnia te funkcje:

• registerCallback, aby zastąpić IBatteryPropertiesRegistrar.registerListener
• unregisterCallback, aby zastąpić IBatteryPropertiesRegistrar.unregisterListener
• update, aby zastąpić IBatteryPropertiesRegistrar.scheduleUpdate
• IBatteryPropertiesRegistrar.getProperties są zastępowane przez te wartości:
  • getChargeCounter
  • getCurrentNow
  • getCurrentAverage
  • getCapacity
  • getEnergyCounter
  • getChargeStatus
  • getHealthInfo

Dodatkowo IHealth udostępnia te nowe interfejsy API dla storaged, aby pobierać informacje o przechowywaniu danych:

• getStorageInfo
• getDiskStats

Wywołanie zwrotne i getHealthInfo zwracają nową strukturę (@2.0::HealthInfo). Ta struktura zawiera wszystkie informacje o stanie urządzenia dostępne za pomocą interfejsu Health@2.0 HAL, w tym:

• informacje o ładowaniu (zasilanie z sieci/USB/bezprzewodowe, prąd, napięcie itp.);
• informacje o baterii (obecność, poziom naładowania, prąd, napięcie, ładowanie, technologia itp.);
• Informacje o miejscu na dane (informacje o urządzeniu pamięci masowej, statystyki dysku)

Informacje o wdrażaniu usługi Health 2.0 znajdziesz w artykule Wdrażanie usługi Health 2.0.

Interfejs HAL HIDL 2.1

Interfejs HAL health@2.1 obsługuje ładowanie w trybie offline i zawiera więcej informacji o baterii.

Główny interfejs, IHealth, udostępnia następujące dodatkowe funkcje:

• getHealthConfig: pobieranie konfiguracji tej HAL
• getHealthInfo_2_1: uaktualnienie wersji podrzędnej do wersji getHealthInfo
• shouldKeepScreenOn: określenie, czy ekran ma być włączony w trybie ładowania.

Ponadto implementacja @2.1::IHealth musi obsługiwać klasę @2.1::IHealthInfoCallback w przypadku dziedziczonych funkcji registerCallback i unregisterCallback. Nowy interfejs wywołania zwrotnego zwraca informacje o zdrowie do klienta za pomocą funkcji healthInfoChanged_2_1 zamiast dziedziczonej funkcji healthInfoChanged.

Nowa struktura @2.1::HealthInfo jest zwracana przez funkcje zwracane i getHealthInfo_2_1. Ta struktura zawiera dodatkowe informacje o stanie urządzenia dostępne w interfejsie HAL dla Health@2.0, w tym:

• Poziom naładowania baterii
• Czas ładowania baterii do pełnego naładowania (w sekundach)
• Pojemność całkowita naładowana do pełnego naładowania (w μAh)

Poniżej znajdziesz diagram UML z klasami przydatnymi do implementacji interfejsu HAL w przypadku opieki zdrowotnej:

Rysunek 7. Diagram UML HAL 2.1 w zakresie zdrowia.

Informacje o wdrażaniu usługi Health 2.1 znajdziesz w artykule Wdrażanie usługi Health 2.1.

Wersja interfejsu AIDL HAL 1

Zmiany w interfejsie API

Interfejs AIDL w wersji 1 obsługuje podobne interfejsy API jak interfejs HIDL 2.1. W porównaniu z interfejsem HIDL 2.1 w interfejsie API wprowadzono następujące zmiany:

• Interfejsy API związane z ładowarką wprowadzone w HIDL HAL 2.1 nie są przenoszone do interfejsu AIDL HAL. Funkcja ładowania w trybie offline działa tylko na partycji /vendor, więc interfejsy API w interfejsie dostawcy nie są potrzebne. Aby prawidłowo wdrożyć ładowanie w trybie wyłączonym, przeczytaj sekcję dotyczącą ładowarki poniżej.
• Typ StorageAttribute i powiązane z nim pola zostały usunięte, ponieważ nie są używane.
• Do HealthInfo dodano chargerDockOnline, aby umożliwić ładowanie na stacji dokującej.

Implementacja

Poniżej znajdziesz diagram UML z klasami przydatnymi do implementacji interfejsu HAL w przypadku opieki zdrowotnej:

Rysunek 8. Schemat UML AIDL HAL.

Informacje o wdrażaniu usługi AIDL dotyczącej zdrowia znajdziesz w artykule Wdrażanie interfejsu HAL AIDL dotyczącego zdrowia.

Odzyskiwanie

Android 13 obsługuje tworzenie powiązania podczas przywracania. Zainstalowanie usługi Health AIDL w trybie odzyskiwania umożliwia jej działanie w tym trybie.

Informacje o instalowaniu usługi Health AIDL w systemie przywracania znajdziesz w tych artykułach:

• Korzystanie z przykładowej usługi HAL AIDL dotyczącej zdrowia
• Zmiany w systemie kompilacji

Ładowarka

Funkcja ładowania w trybie wyłączenia została przeniesiona z /system do /vendor. W przypadku urządzeń z Androidem 13, które obsługują ładowanie w trybie wyłączonym, binarny plik usługi HAL musi obsługiwać tryb ładowania. Aby to zrobić, zapoznaj się z informacjami na temat wdrażania ładowarki.

Właściwości systemu ładowarki

Właściwości ro.charger.* nie są już czytelne dla binarnego pliku charger w pliku /vendor. Jeśli na urządzeniu ustawiono jedną z właściwości systemowych ro.charger.*, zapoznaj się z właściwościami systemowymi ładowarki.