Cały kod healthd
został przebudowany na health@2.0-impl i libhealthservice
, a następnie zmodyfikowany w celu implementacji health@2.0 HAL. Te dwie biblioteki są połączone statycznie przez usługę health@2.0, umożliwiając jej wykonanie pracy wykonanej wcześniej przez healthd
(tzn. uruchomienie healthd_mainloop
i wykonanie odpytywania). W init usługa health@2.0 rejestruje implementację interfejsu IHealth
do hwservicemanager
. W przypadku aktualizacji urządzeń z obrazem dostawcy systemu Android 8.x i strukturą systemu Android 9 obraz dostawcy może nie zapewniać usługi health@2.0. Jest to wymuszane przez harmonogram wycofywania .
Aby rozwiązać ten problem:
-
healthd
rejestrujeIHealth
whwservicemanager
(mimo że jest demonem systemowym).IHealth
zostanie dodany do manifestu systemowego z nazwą instancji"backup"
. - Framework i
storaged
komunikują się zhealthd
poprzezhwbinder
zamiastbinder
. - Kod dla frameworka i
storaged
został zmieniony, aby pobrać instancję"default"
jeśli jest dostępna, a następnie"backup"
.- 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 zdefiniować wartości specyficznych dla płyty dla modułów systemu. W health@2.0 dostawcy mogą zastąpić te dwie wartości w healthd_mode_ops->init
(poprzez usunięcie zależności libhealthservice
w health@2.0-service.<device>
i ponowne wdrożenie tej funkcji).
Biblioteka implementacji statycznej
W przeciwieństwie do innych bibliotek implementacji HAL, biblioteka implementacji health@2.0-impl jest biblioteką statyczną , do której prowadzą łącza health@2.0-service, ładowarka, odzyskiwanie i starsze rozwiązania Healthd.
health@2.0.impl implementuje IHealth
zgodnie z powyższym opisem i ma obejmować libbatterymonitor
i libhealthd. BOARD
. Tym użytkownikom health@2.0-impl nie wolno bezpośrednio używać BatteryMonitor
ani funkcji libhealthd
; zamiast tego wywołania te należy zastąpić wywołaniami klasy Health
, która jest implementacją interfejsu IHealth
. Aby dalej uogólniać, kod healthd_common
jest również zawarty w health@2.0-impl. Nowy healthd_common
zawiera resztę wspólnego kodu między usługą health@2.0, ładowarką i healthd
oraz wywołuje metody IHealth zamiast BatteryMonitor.
Wdróż usługę Zdrowie 2.0
Podczas wdrażania usługi health@2.0 dla urządzenia, jeśli domyślna implementacja to:
- Wystarczy dla urządzenia, użyj bezpośrednio
android.hardware.health@2.0-service
. Nie wystarczy dla urządzenia. Utwórz plik wykonywalny
android.hardware.health@2.0-service.(device)
i dołącz:#include <health2/service.h> int main() { return health_service_main(); }
Następnie:
Jeśli
libhealthd:
- Istnieje, link do niego.
- Nie istnieje, podaj puste implementacje funkcji
healthd_board_init
ihealthd_board_battery_update
.
Jeśli zmienne
BOARD_PERIODIC_CHORES_INTERVAL_*
specyficzne dla płyty:- Są zdefiniowane, utwórz
HealthServiceCommon.cpp
specyficzny dla urządzenia (skopiowany zhardware/interfaces/health/2.0/utils/libhealthservice
) i dostosuj go whealthd_mode_service_2_0_init
. - Nie są zdefiniowane, łącze do
libhealthservice
statycznie.
- Są zdefiniowane, utwórz
Jeśli urządzenie:
- Powinien zaimplementować API
getStorageInfo
igetDiskStats
, zapewnić implementację w funkcjachget_storage_info
iget_disk_stats
. - Nie należy implementować tych interfejsów API, link do
libstoragehealthdefault
statycznie.
- Powinien zaimplementować API
Zaktualizuj niezbędne uprawnienia SELinux.
Zaimplementuj warstwę HAL podczas odzyskiwania, instalując implementację przekazującą do obrazu odzyskiwania. Przykład:
// Android.bp cc_library_shared { name: "android.hardware.health@2.0-impl-<device>", recovery_available: true, relative_install_path: "hw", static_libs: [ "android.hardware.health@2.0-impl", "libhealthd.<device>" // Include the following or implement device-specific storage APIs "libhealthstoragedefault", ], srcs: [ "HealthImpl.cpp", ], overrides: [ "android.hardware.health@2.0-impl-default", ], }
// HealthImpl.cpp #include <health2/Health.h> #include <healthd/healthd.h> using android::hardware::health::V2_0::IHealth; using android::hardware::health::V2_0::implementation::Health; extern "C" IHealth* HIDL_FETCH_IHealth(const char* name) { const static std::string providedInstance{"default"}; if (providedInstance != name) return nullptr; return Health::initInstance(&gHealthdConfig).get(); }
# device.mk PRODUCT_PACKAGES += android.hardware.health@2.0-impl-<device>
Szczegółowe informacje można znaleźć w pliku hardware/interfaces/health/2.0/README.md .
Klienci zdrowia
Zobacz Klienci kondycji dla Zdrowie 2.1 HAL .
Zmiany w SELinuxie
Nowa wersja HAL health@2.0 zawiera następujące zmiany w SELinux:
- Dodaje usługę health@2.0 do
file_contexts
. - Umożliwia
system_server
istoraged
używaniehal_health
. - Zezwala
system_server
(BatteryService
) na zarejestrowaniebatteryproperties_service
(IBatteryPropertiesRegistrar
). - Pozwala
healthd
zapewnićhal_health
. - Usuwa reguły, które pozwalają
system_server
istoraged
na odwoływanie się dohealthd
poprzez spoiwo. - Usuwa reguły, które pozwalają
healthd
zarejestrowaćbatteryproperties_service
(IBatteryPropertiesRegistrar
).
W przypadku urządzeń z własną implementacją mogą być konieczne pewne zmiany dostawcy SELinux. Przykład:
# device/<manufacturer>/<device>/sepolicy/vendor/file_contexts
/vendor/bin/hw/android\.hardware\.health@2\.0-service.<device> u:object_r:hal_health_default_exec:s0
# 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
Zobacz Interfejsy jądra dla Health 2.1 HAL .
Testowanie
Android 9 zawiera nowe testy VTS napisane specjalnie dla HAL health@2.0. Jeżeli urządzenie w manifeście urządzenia zadeklaruje zapewnianie HAL health@2.0, musi 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
Zobacz Wymagania dotyczące informacji o baterii .