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:

  1. healthd rejestruje IHealth w hwservicemanager (mimo że jest demonem systemowym). IHealth zostanie dodany do manifestu systemowego z nazwą instancji „backup”.
  2. Framework i storaged komunikują się z healthd poprzez hwbinder zamiast binder .
  3. 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 .
  4. 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 .

,

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:

  1. healthd rejestruje IHealth w hwservicemanager (mimo że jest demonem systemowym). IHealth zostanie dodany do manifestu systemowego z nazwą instancji „backup”.
  2. Framework i storaged komunikują się z healthd poprzez hwbinder zamiast binder .
  3. 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 .
  4. 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 .