Implementare la Salute 2.0

Tutto il codice healthd è stato rifattorizzato in Health@2.0-impl e libhealthservice , quindi modificato per implementare Health@2.0 HAL. Queste due librerie sono collegate staticamente da Health@2.0-service, consentendogli di svolgere il lavoro precedentemente svolto da healthd (ovvero eseguire healthd_mainloop ed eseguire il polling). In init, il servizio health@2.0 registra un'implementazione dell'interfaccia IHealth su hwservicemanager . Quando si aggiornano i dispositivi con un'immagine del fornitore Android 8.x e un framework Android 9, il servizio Health@2.0 potrebbe non essere fornito dall'immagine del fornitore. Ciò è imposto dal programma di deprecazione .

Per risolvere questo problema:

  1. healthd registra IHealth su hwservicemanager (nonostante sia un demone di sistema). IHealth viene aggiunto al manifesto del sistema, con il nome di istanza "backup".
  2. Framework e storaged comunicano con healthd tramite hwbinder anziché binder .
  3. Il codice per framework e storaged viene modificato per recuperare l'istanza "default" se disponibile, quindi "backup".
    • Il codice client C++ utilizza la logica definita in libhealthhalutils .
    • Il codice client Java utilizza la logica definita in HealthServiceWrapper .
  4. Dopo che IHealth/default sarà ampiamente disponibile e le immagini del fornitore Android 8.1 saranno deprecate, IHealth/backup e healthd potranno essere deprecate. Per ulteriori dettagli, vedere Deprecazione di salute@1.0 .

Variabili di build specifiche della scheda per Healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sono variabili specifiche della scheda utilizzate per creare healthd . Come parte della suddivisione della build del sistema/fornitore, non è possibile definire valori specifici della scheda per i moduli di sistema. In Health@2.0, i fornitori possono sovrascrivere questi due valori in healthd_mode_ops->init (eliminando la dipendenza libhealthservice in health@2.0-service.<device> e reimplementando questa funzione).

Libreria di implementazione statica

A differenza di altre librerie di implementazione HAL, la libreria di implementazione Health@2.0-impl è una libreria statica a cui si collegano Health@2.0-service, Charger, Recovery e legacy Healthd.

health@2.0.impl implementa IHealth come descritto sopra ed è pensato per racchiudere libbatterymonitor e libhealthd. BOARD . Questi utenti di Health@2.0-impl non devono utilizzare direttamente BatteryMonitor o le funzioni di libhealthd ; queste chiamate dovrebbero invece essere sostituite con chiamate alla classe Health , un'implementazione dell'interfaccia IHealth . Per generalizzare ulteriormente, il codice healthd_common è incluso anche in Health@2.0-impl. Il nuovo healthd_common contiene il resto del codice comune tra Health@2.0-service, Charger e healthd e richiama i metodi IHealth anziché BatteryMonitor.

Implementazione del servizio Salute 2.0

Quando si implementa il servizio Health@2.0 per un dispositivo, se l'implementazione predefinita è:

  • Sufficiente per il dispositivo, utilizzare direttamente android.hardware.health@2.0-service .
  • Non sufficiente per il dispositivo, crea l'eseguibile android.hardware.health@2.0-service.(device) e includi:

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

Poi:

  • Se libhealthd:

    • Esiste, linkalo.
    • Non esiste, fornisce implementazioni vuote per le funzioni healthd_board_init e healthd_board_battery_update .
  • Se variabili BOARD_PERIODIC_CHORES_INTERVAL_* specifiche della scheda:

    • Se vengono definiti, creare un HealthServiceCommon.cpp specifico del dispositivo (copiato da hardware/interfaces/health/2.0/utils/libhealthservice ) e personalizzarlo in healthd_mode_service_2_0_init .
    • Non sono definiti, collegamento statico a libhealthservice .
  • Se dispositivo:

    • Dovrebbe implementare le API getStorageInfo e getDiskStats , fornire l'implementazione nelle funzioni get_storage_info e get_disk_stats .
    • Non dovresti implementare tali API, collegarti a libstoragehealthdefault in modo statico.
  • Aggiorna le autorizzazioni SELinux necessarie.

  • Implementare l'HAL nel ripristino installando un'implementazione passthrough nell'immagine di ripristino. Esempio:

    // 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>
    

Per i dettagli, fare riferimento a hardware/interfaces/health/2.0/README.md .

Clienti sanitari

Vedere Clienti sanitari per Health 2.1 HAL .

SELinux cambia

Il nuovo HAL salute@2.0 include le seguenti modifiche SELinux:

  • Aggiunge Health@2.0-service a file_contexts .
  • Consente system_server e storaged di utilizzare hal_health .
  • Consente system_server ( BatteryService ) di registrare batteryproperties_service ( IBatteryPropertiesRegistrar ).
  • Consente healthd di fornire hal_health .
  • Rimuove le regole che consentono system_server / storaged di chiamare healthd tramite binder.
  • Rimuove le regole che consentono healthd di registrare batteryproperties_service ( IBatteryPropertiesRegistrar ).

Per i dispositivi con la propria implementazione, potrebbero essere necessarie alcune modifiche al fornitore SELinux. Esempio:

# 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.

Interfacce del kernel

Vedere Interfacce del kernel per HAL integrità 2.1 .

Test

Android 9 include nuovi test VTS scritti appositamente per l'HAL Health@2.0. Se un dispositivo dichiara di fornire HAL Health@2.0 nel manifest del dispositivo, deve superare i test VTS corrispondenti. I test vengono scritti sia per l'istanza predefinita (per garantire che il dispositivo implementi correttamente l'HAL) sia per l'istanza di backup (per garantire che healthd continui a funzionare correttamente prima che venga rimosso).

Requisiti informativi sulla batteria

Vedere Requisiti informativi sulla batteria .