Wdróż Health 2.0

Cały kod healthd został przekształcony w health@2.0-impl i libhealthservice, a następnie zmodyfikowany w celu implementacji interfejsu HAL health@2.0. Te 2 biblioteki są połączone statycznie przez usługę health@2.0, co umożliwia jej wykonywanie zadań, które wcześniej wykonywała usługa healthd (czyli uruchamianie funkcji healthd_mainloop i odpytywanie). W init usługa health@2.0-service rejestruje implementację interfejsu IHealth w interfejsie hwservicemanager. Podczas uaktualniania urządzeń z obrazem dostawcy Androida 8.x i platformą Android 9 usługa Health@2.0 może nie być dostarczana przez obraz dostawcy. Jest to wymuszane przez harmonogram wycofywania.

Aby rozwiązać ten problem:

  1. healthd rejestruje IHealth jako hwservicemanager (pomimo że jest to demon systemowy). Plik IHealth został dodany do pliku manifestu systemu z nazwą instancji "backup".
  2. Framework i storaged komunikują się z healthd przez hwbinder zamiast przez binder.
  3. Kod frameworka i funkcji storaged został zmieniony, aby pobierać instancję "default", jeśli jest dostępna, a potem "backup".
    • Kod klienta C++ korzysta z logiki zdefiniowanej w zasadzie libhealthhalutils.
    • Kod klienta w języku Java korzysta z logiki zdefiniowanej w pliku HealthServiceWrapper.
  4. Gdy IHealth/domyślne będzie powszechnie dostępne, a obrazy dostawcy Androida 8.1 zostaną wycofane, można wycofać IHealth/domyślne i healthd. Więcej informacji znajdziesz w artykule Wycofanie obsługi interfejsu Health@1.0.

Zmienne kompilacji dotyczące healthd związane z poszczególnymi płytami

BOARD_PERIODIC_CHORES_INTERVAL_* to zmienne powiązane z konkretną tablicą, używane do tworzenia healthd. W ramach podziału kompilacji systemu/dostawcy nie można zdefiniować wartości dla modułów systemowych na poziomie płyt. W health@2.0 dostawcy mogą zastąpić te 2 wartości w funkcji healthd_mode_ops->init (poprzez usunięcie zależności libhealthservice w funkcji health@2.0-service.<device> i ponownie wdrożenie tej funkcji).

Statyczna biblioteka implementacji

W przeciwieństwie do innych bibliotek implementacji HAL biblioteka implementacji Health@2.0-impl to statyczna biblioteka, w której usługa Health@2.0-service, ładowarka, odzysk i starszy link o stanie prawidłowym.

health@2.0.impl implementuje interfejs IHealth zgodnie z opisem powyżej i ma za zadanie otaczanie interfejsów libbatterymonitor i libhealthd.BOARD. Użytkownicy biblioteki health@2.0-impl nie mogą bezpośrednio używać interfejsu BatteryMonitor ani funkcji w libhealthd. Zamiast tego te wywołania należy zastąpić wywołaniami klasy Health, która jest implementacją interfejsu IHealth. Aby uogólniać, healthd_common kod jest też zawarty w health@2.0-impl. Nowa wersja healthd_common zawiera resztę kodu wspólnego dla usługi Health@2.0, ładowarki oraz healthd i wywołuje metody IHealth zamiast BatteryMonitor.

Wdrożenie usługi Health 2.0

Podczas implementowania usługi health@2.0 na urządzeniu, jeśli domyślna implementacja:

  • 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 uwzględnij:

    #include <health2/service.h>
int main() { return health_service_main(); }

Następnie:

  • Jeśli dotyczy tablicy: libhealthd:

    • Istnieje, link do niego.
    • Nie istnieje, podaj puste implementacje funkcji healthd_board_init i healthd_board_battery_update.

  • W przypadku zmiennych BOARD_PERIODIC_CHORES_INTERVAL_* właściwych dla danej tablicy:

    • są zdefiniowane, utwórz plik HealthServiceCommon.cpp (skopiowany z pliku hardware/interfaces/health/2.0/utils/libhealthservice) i skonfiguruj go w sekcji healthd_mode_service_2_0_init.
    • Nie są zdefiniowane, łączą się statycznie z libhealthservice.

  • Jeśli urządzenie:

    • Jeśli chcesz zaimplementować interfejsy API getStorageInfo i getDiskStats, podaj implementację w funkcjach get_storage_info i get_disk_stats.
    • Nie należy implementować tych interfejsów API, ale libstoragehealthdefaultlinkować do nich w sposób statyczny.

  • Zaktualizuj niezbędne uprawnienia SELinux.

  • Wdróż HAL podczas przywracania, instalując implementację przekazującą do obrazu przywracania. 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 znajdziesz na stronie sprzęt/interfejsy/health/2.0/README.md.

Klienci z zakresu zdrowia

Zobacz klientów Health 2.1 HAL.

Zmiany w SELinux

Nowy interfejs HAL health@2.0 zawiera te zmiany w SELinux:

  • Dodaje Health@2.0-service do file_contexts.
  • Zezwalaj użytkownikom system_server i storaged na korzystanie z hal_health.
  • Zezwalanie użytkownikowi system_server (BatteryService) na rejestrację batteryproperties_service (IBatteryPropertiesRegistrar).
  • Umożliwia healthd udostępnianie hal_health.
  • Usuwa reguły, które umożliwiają system_server i storaged wywoływanie funkcji healthd za pomocą bindera.
  • Usuwa reguły, które zezwalają healthd na rejestrowanie batteryproperties_service (IBatteryPropertiesRegistrar).

W przypadku urządzeń z własną implementacją może być konieczne wprowadzenie pewnych zmian w SELinux przez dostawcę. 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 systemu w Health 2.1 HAL.

Testowanie

Android 9 zawiera nowe testy VTS napisane specjalnie pod kątem HAL Health@2.0. Jeśli w pliku manifestu urządzenia deklarujesz, że zapewniasz interfejs HAL health@2.0, musisz przejść odpowiednie testy VTS. Testy są zapisywane zarówno dla instancji domyślnej (aby sprawdzić, czy urządzenie poprawnie implementuje kod HAL), jak i instancji kopii zapasowej (aby zapewnić prawidłowe działanie usługi healthd przed jej usunięciem).

Wymagania dotyczące informacji o baterii

Zobacz wymagania dotyczące informacji o baterii.