Implementa Salute 2.0

Tutto il codice di healthd è stato rielaborato in health@2.0-impl e libhealthservice, quindi modificato per implementare health@2.0 HAL. Questi due le librerie sono collegate in modo statico dal servizio health@2.0, il che consente di svolgere operazioni precedentemente eseguite da healthd (ovvero, esegui healthd_mainloop e sondaggio). In init, il servizio health@2.0 registra un'implementazione del metodo dall'interfaccia IHealth a hwservicemanager. Quando esegui l'upgrade dei dispositivi con un Immagine del fornitore Android 8.x e framework Android 9, il servizio health@2.0 potrebbe non essere fornito dall'immagine del fornitore. Questa norma viene applicata dal pianificazione del ritiro.

Per risolvere il problema:

  1. healthd registra IHealth in hwservicemanager (nonostante sia un sistema daemon). IHealth viene aggiunto al manifest di sistema con il nome istanza "backup".
  2. Il framework e storaged comunicano con healthd tramite hwbinder anziché binder.
  3. Il codice per il framework e storaged sono stati modificati per recuperare l'istanza "default" se disponibile, poi "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 dei fornitori di Android 8.1 vengono deprecati, IHealth/backup e healthd possono essere ritirati. Per ulteriori informazioni Vedi Ritiro dell'integrità@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/fornitore, i valori specifici del consiglio di amministrazione non può essere definito per i moduli di sistema. In health@2.0, i fornitori possono eseguire l'override questi due valori in healthd_mode_ops->init (riducendo libhealthservice dipendenza in health@2.0-service.<device> e la reimplementazione di 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 health@2.0-service, caricatore, ripristino e link con integrità legacy.

health@2.0.impl implementa IHealth come descritto sopra e ha lo scopo di aggregare intorno a libbatterymonitor e libhealthd.BOARD. Questi gli utenti di health@2.0-impl non devono utilizzare BatteryMonitor o le funzioni in libhealthd direttamente; queste chiamate devono essere sostituite da chiamate classe Health, un'implementazione dell'interfaccia IHealth. Per generalizzare inoltre, 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, caricabatterie, healthd e chiamate a metodi IHealth invece che BatteryMonitor.

Implementare il servizio Health 2.0

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

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

  • Non sufficiente per il dispositivo. Crea l'elemento android.hardware.health@2.0-service.(device) eseguibili e includono:

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

Quindi:

  • Se le specifiche della scheda di amministrazione sono libhealthd:

    • Esiste, collegalo.
    • Non esiste, fornisci implementazioni vuote per healthd_board_init e healthd_board_battery_update.

  • Se le variabili BOARD_PERIODIC_CHORES_INTERVAL_* specifiche della scheda:

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

  • Se il dispositivo:

    • Devi implementare le API getStorageInfo e getDiskStats, fornisci le l'implementazione nelle funzioni get_storage_info e get_disk_stats.
    • Non implementare queste API, collega a libstoragehealthdefault in modo statico.

  • Aggiorna le autorizzazioni SELinux necessarie.

  • Implementare HAL nel ripristino installando un'implementazione passthrough nel 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 sanitari

Vedi Client sanitari per HAL 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 registrarsi 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 una propria implementazione, alcune modifiche SELinux del fornitore potrebbero essere necessaria. 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 i nuovi test VTS e scritte appositamente per health@2.0 HAL. Se un dispositivo dichiara di fornire health@2.0 HAL nel file manifest del dispositivo, deve superare i corrispondenti test VTS. I test vengono scritti sia per l'istanza predefinita (per garantire che il implementi correttamente l'HAL) e l'istanza di backup (per garantire che healthd continui a funzionare correttamente prima di essere rimossi).

Requisiti relativi alle informazioni sulla batteria

Consulta i requisiti relativi alle informazioni sulla batteria.