Implementa Salute 2.0

Tutto il codice di healthd è stato sottoposto a refactoring in health@2.0-impl e libhealthservice, quindi modificato per implementare health@2.0 HAL. Queste due librerie sono collegate in modo statico da health@2.0-service, che può 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 in hwservicemanager. Quando esegui l'upgrade dei 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 applicato in base al programma di ritiro.

Per risolvere il problema:

  1. healthd registra IHealth in hwservicemanager (nonostante sia un daemon di sistema). IHealth viene aggiunto al manifest di sistema con il nome dell'istanza "backup".
  2. Il framework e storaged comunicano con healthd tramite hwbinder anziché binder.
  3. Il codice per il 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. Una volta che IHealth/default sarà ampiamente disponibile e le immagini dei fornitori di Android 8.1 verranno ritirate, IHealth/backup e healthd potranno essere deprecati. Per maggiori dettagli, consulta Ritiro di health@1.0.

Variabili di build specifiche della scheda di amministrazione per l'integrità

BOARD_PERIODIC_CHORES_INTERVAL_* sono variabili specifiche della scheda utilizzate per creare healthd. Nell'ambito della suddivisione della build del sistema/del fornitore, non è possibile definire valori specifici della scheda per i moduli di sistema. In health@2.0, i fornitori possono eseguire l'override di questi due valori in healthd_mode_ops->init (rimuovendo la dipendenza da 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 healthd legacy.

health@2.0.impl implementa IHealth come descritto sopra ed è pensato per essere inserito in libbatterymonitor e libhealthd.BOARD. Questi utenti di health@2.0-impl non devono utilizzare BatteryMonitor o le funzioni in libhealthd direttamente; al contrario, queste chiamate devono essere sostituite con chiamate alla classe Health, un'implementazione dell'interfacciaIHealth. 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 chiama i metodi IHealth anziché BatteryMonitor.

Implementare il servizio Health 2.0

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

  • Sufficiente per il dispositivo, usa android.hardware.health@2.0-service direttamente.

  • Non sufficiente per il dispositivo, crea l'eseguibileandroid.hardware.health@2.0-service.(device) e includi:

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

Quindi:

  • Se specifico per la scheda libhealthd:

    • Esiste, inserisci il link.
    • Non esiste, fornisci implementazioni vuote per le funzioni healthd_board_init e healthd_board_battery_update.

  • Se le variabili BOARD_PERIODIC_CHORES_INTERVAL_* sono specifiche della scheda:

    • Sono definiti, crea un HealthServiceCommon.cpp specifico per il dispositivo (copiato da hardware/interfaces/health/2.0/utils/libhealthservice) e personalizzalo in healthd_mode_service_2_0_init.
    • Non sono definiti, esegui il collegamento a libhealthservice in modo statico.

  • Se il dispositivo:

    • Se devi implementare le API getStorageInfo e getDiskStats, fornisci l'implementazione nelle funzioni get_storage_info e get_disk_stats.
    • Non devi implementare queste API, ma devi collegarti a libstoragehealthdefault staticamente.

  • 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 maggiori dettagli, consulta hardware/interfaces/health/2.0/README.md.

Client di salute

Consulta Client di salute per HAL di Salute 2.1.

Modifiche a SELinux

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

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

Per i dispositivi con implementazione propria, potrebbero essere necessarie alcune modifiche SELinux del fornitore. 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

Vedi Interfacce del kernel per HAL 2.1 per l'integrità.

Test

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

Requisiti relativi alle informazioni sulla batteria

Consulta i requisiti relativi alle informazioni sulla batteria.