Questa pagina è stata tradotta dall'API Cloud Translation.

Implementazione della 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:

healthd registra IHealth su hwservicemanager (nonostante sia un demone di sistema). IHealth viene aggiunto al manifesto del sistema, con il nome di istanza "backup".
Framework e storaged comunicano con healthd tramite hwbinder anziché binder .
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 .
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 di 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 .