Implementazione della salute 2.0

Tutti healthd codice è stata riscritta in health@2.0-impl e libhealthservice , poi modificato per implementare health@2.0 HAL. Questi due librerie sono collegate staticamente dai health@2.0-service, permettendogli di fare il lavoro fatto in precedenza da healthd (cioè eseguire il healthd_mainloop e fare polling). In init, il health@2.0-service registra un'implementazione dell'interfaccia IHealth a 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. Questo viene applicata dal programma deprecazione .

Per risolvere questo problema:

  1. healthd registra IHealth a hwservicemanager (pur essendo un demone di sistema). IHealth viene aggiunto al sistema di manifesti, con nome di istanza "backup".
  2. Quadro e storaged comunicano con healthd via hwbinder invece di binder .
  3. Codice per quadro e storaged vengono modificati per andare a prendere l'istanza di "default", se disponibile, quindi "backup".
    • C ++ codice client utilizza la logica definita in libhealthhalutils .
    • Java codice client utilizza la logica definita in HealthServiceWrapper .
  4. Dopo iHealth / default è ampiamente disponibile e immagini Android 8.1 vendor sono deprecati, iHealth / backup e healthd può essere deprecato. Per maggiori dettagli, vedere deprecando health@1.0 .

Variabili di build specifiche della scheda per healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sono variabili specifiche pensione usato per costruire healthd . Come parte del sistema / fornitore accumulo divisione, valori bordo-specifici non possono essere definiti per moduli di sistema. In health@2.0, fornitori possono sostituire questi due valori in healthd_mode_ops->init (facendo cadere libhealthservice dipendenza nel health@2.0-service.<device> e ri-esecuzione di questa funzione).

Libreria di implementazione statica

A differenza di altre librerie di implementazione HAL, il health@2.0-impl biblioteca implementazione è una libreria statica a cui health@2.0-service, il caricatore, il recupero, e il collegamento eredità healthd.

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

Implementazione del servizio Health 2.0

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

  • Sufficiente per il dispositivo, utilizzare android.hardware.health@2.0-service direttamente.
  • Non è sufficiente per il dispositivo, creare android.hardware.health@2.0-service.(device) Eseguibile e comprendono:

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

Quindi:

  • Se board-specifica libhealthd:

    • Esiste, collegalo.
    • Non esiste, fornire implementazioni vuote per healthd_board_init e healthd_board_battery_update funzioni.
  • Se board-specifica BOARD_PERIODIC_CHORES_INTERVAL_* variabili:

    • Sono definiti, creare un dispositivo specifico HealthServiceCommon.cpp (copiato da hardware/interfaces/health/2.0/utils/libhealthservice ) e personalizzarlo in healthd_mode_service_2_0_init .
    • Non sono definite, link per libhealthservice staticamente.
  • Se dispositivo:

    • Dovrebbe attuare getStorageInfo e getDiskStats API, fornisce l'implementazione in get_storage_info e get_disk_stats funzioni.
    • Non dovrebbe implementare queste API, un collegamento a libstoragehealthdefault staticamente.
  • Aggiorna i permessi SELinux necessari.

  • Implementare 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 ulteriori informazioni, fare riferimento a hardware / interfacce / salute / 2.0 / README.md .

Clienti sanitari

Vedere clienti Salute per la salute 2.1 HAL .

SELinux cambia

Il nuovo HAL health@2.0 include le seguenti modifiche a SELinux:

  • Health@2.0-service aggiunge file_contexts .
  • Permette system_server e storaged all'uso hal_health .
  • Consente system_server ( BatteryService ) per registrare batteryproperties_service ( IBatteryPropertiesRegistrar ).
  • Consente healthd per fornire hal_health .
  • Rimuove le regole che consentono system_server / storaged di rimettere in healthd via legante.
  • Rimuove le regole che permettono healthd per 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 la salute 2.1 HAL .

test

Android 9 include nuove VTS prove scritte appositamente per l'HAL health@2.0. Se un dispositivo dichiara di fornire health@2.0 HAL nel manifest del dispositivo, deve superare i corrispondenti test VTS. I test vengono scritti sia per l'istanza predefinita (per assicurare che gli attrezzi del dispositivo della HAL correttamente) e l'istanza di backup (per garantire che healthd continua correttamente funzione prima di essere rimosso).

Requisiti per le informazioni sulla batteria

Vedere requisiti di informazione della batteria .