Ta strona została przetłumaczona przez Cloud Translation API.

Wdrażanie zdrowia 2.0

Cały kod w dobrej kondycji został przerobiony na healthd i libhealthservice , a następnie zmodyfikowany w celu zaimplementowania health@2.0 HAL. Te dwie biblioteki są połączone statycznie przez health@2.0-service, co umożliwia wykonanie pracy wykonanej wcześniej przez healthd (tj. uruchomienie healthd_mainloop i odpytywanie). W init usługa health@2.0-service rejestruje implementację interfejsu IHealth do hwservicemanager . Podczas uaktualniania urządzeń z obrazem dostawcy systemu Android 8.x i strukturą systemu Android 9 usługa health@2.0 może nie być zapewniana przez obraz dostawcy. Jest to wymuszane przez harmonogram wycofywania .

Aby rozwiązać ten problem:

healthd rejestruje IHealth w hwservicemanager (pomimo bycia demonem systemowym). IHealth jest dodawany do manifestu systemowego z nazwą instancji „backup”.
Framework i storaged komunikują się z healthd za pośrednictwem hwbinder zamiast binder .
Kod dla struktury i storaged jest zmieniany, aby pobrać instancję „domyślnie”, jeśli jest dostępna, a następnie „kopia zapasowa”.
- Kod klienta C++ używa logiki zdefiniowanej w libhealthhalutils .
- Kod klienta Java korzysta z logiki zdefiniowanej w HealthServiceWrapper .
Gdy IHealth/default jest powszechnie dostępny, a obrazy dostawców systemu Android 8.1 są przestarzałe, IHealth/backup i healthd mogą zostać wycofane. Aby uzyskać więcej informacji, zobacz Deprecating health@1.0 .

Zmienne kompilacji specyficzne dla płyty dla zdrowego

BOARD_PERIODIC_CHORES_INTERVAL_* to zmienne specyficzne dla płyty używane do budowania healthd . W ramach podziału kompilacji systemu/dostawcy nie można definiować wartości specyficznych dla płyty dla modułów systemowych. W health@2.0 dostawcy mogą zastąpić te dwie wartości w healthd_mode_ops->init (poprzez porzucenie zależności libhealthservice w health@2.0-service.<device> i ponowne zaimplementowanie 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 łącze health@2.0-service, ładowarka, odzyskiwanie i starsze łącze o kondycji jest starsze.

health@2.0.impl implementuje IHealth zgodnie z powyższym opisem i ma na celu zawinięcie wokół libbatterymonitor i libhealthd. BOARD . Ci użytkownicy health@2.0-impl nie mogą bezpośrednio używać BatteryMonitor ani funkcji w libhealthd ; zamiast tego wywołania te powinny zostać zastąpione wywołaniami klasy Health , implementacji interfejsu IHealth . Aby uogólnić dalej, 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-service, ładowarką i healthd oraz wywołuje metody IHealth zamiast BatteryMonitor.

Wdrożenie usługi Health 2.0

Podczas wdrażania usługi health@2.0 dla urządzenia, jeśli domyślna implementacja to:

Wystarczające dla urządzenia, użyj bezpośrednio android.hardware.health@2.0-service .
Niewystarczające 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 i healthd_board_battery_update .
Jeśli specyficzne dla płyty zmienne BOARD_PERIODIC_CHORES_INTERVAL_* :
- Są zdefiniowane, utwórz plik HealthServiceCommon.cpp specyficzny dla urządzenia (skopiowany z hardware/interfaces/health/2.0/utils/libhealthservice ) i dostosuj go w healthd_mode_service_2_0_init .
- Nie są zdefiniowane, link do libhealthservice statycznie.
Jeśli urządzenie:
- Należy zaimplementować interfejsy API getStorageInfo i getDiskStats , należy wprowadzić implementację w get_storage_info i get_disk_stats .
- Nie należy implementować tych interfejsów API, połącz statycznie z libstoragehealthdefault .
Zaktualizuj niezbędne uprawnienia SELinux.

Zaimplementuj warstwę HAL w odzyskiwaniu, instalując implementację tranzytową w obrazie 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>

Aby uzyskać szczegółowe informacje, zobacz hardware/interfaces/health/2.0/README.md .

Klienci zdrowotni

Zobacz Klienci zdrowia dla zdrowia 2.1 HAL .

Zmiany w SELinuksie

Nowa HAL health@2.0 zawiera następujące zmiany w SELinux:

Dodaje health@2.0-service do file_contexts .
Pozwala system_server i storaged na używanie hal_health .
Umożliwia serwerowi system_server ( BatteryService ) rejestrację batteryproperties_service ( IBatteryPropertiesRegistrar ).
Pozwala healthd zapewnić hal_health .
Usuwa reguły, które pozwalają system_server / storaged na wywołanie do healthd za pośrednictwem bindera.
Usuwa reguły, które umożliwiają healthd rejestrowanie batteryproperties_service ( IBatteryPropertiesRegistrar ).

W przypadku urządzeń z własną implementacją mogą być konieczne zmiany niektórych dostawców 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 kondycji 2.1 HAL .

Testowanie

Android 9 zawiera nowe testy VTS napisane specjalnie dla Health@2.0 HAL. Jeśli urządzenie deklaruje dostarczanie Health@2.0 HAL w manifeście urządzenia, musi przejść odpowiednie testy VTS. Testy są napisane zarówno dla instancji domyślnej (aby upewnić się, że urządzenie poprawnie implementuje warstwę HAL), jak i dla instancji zapasowej (aby upewnić się, że healthd nadal działa poprawnie przed jej usunięciem).

Wymagania dotyczące informacji o bateriach

Zobacz Wymagania dotyczące informacji o bateriach .