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

Wdrażanie zdrowia 2.0

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 (tj. 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 rejestruje IHealth w hwservicemanager (mimo że jest demonem systemowym). IHealth zostanie dodany do manifestu systemowego z nazwą instancji „backup”.
Framework i storaged komunikują się z healthd poprzez hwbinder zamiast binder .
Kod dla frameworka i storaged został zmieniony, aby pobrać instancję „domyślną”, jeśli jest dostępna, a następnie „kopię zapasową”.
- Kod klienta C++ wykorzystuje logikę zdefiniowaną w libhealthhalutils .
- Kod klienta Java używa logiki zdefiniowanej w HealthServiceWrapper .
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ć biblioteki 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ólnić, 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.

Wdrożenie usługi 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 i healthd_board_battery_update .
Jeśli zmienne BOARD_PERIODIC_CHORES_INTERVAL_* specyficzne dla płyty:
- 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 statyczny.
Jeśli urządzenie:
- Powinien zaimplementować API getStorageInfo i getDiskStats , zapewnić implementację w funkcjach 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 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 zdrowia 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 i storaged używanie hal_health .
Umożliwia system_server ( BatteryService ) zarejestrowanie batteryproperties_service ( IBatteryPropertiesRegistrar ).
Pozwala healthd zapewnić hal_health .
Usuwa reguły, które pozwalają system_server / storaged na wywoływanie healthd za pośrednictwem segregatora.
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 kondycji 2.1 HAL .

Testowanie

Android 9 zawiera nowe testy VTS napisane specjalnie dla HAL health@2.0. Jeśli 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 .