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:
healthd
registraIHealth
inhwservicemanager
(nonostante sia un sistema daemon).IHealth
viene aggiunto al manifest di sistema con il nome istanza"backup"
.- Il framework e
storaged
comunicano conhealthd
tramitehwbinder
anzichébinder
. - 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
.
- Il codice client C++ utilizza la logica definita in
- 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
ehealthd_board_battery_update
.
Se le variabili
BOARD_PERIODIC_CHORES_INTERVAL_*
specifiche della scheda:- Vengono definiti, crea un elemento
HealthServiceCommon.cpp
specifico per dispositivo (copiato) dahardware/interfaces/health/2.0/utils/libhealthservice
) e personalizzalo inhealthd_mode_service_2_0_init
. - Non sono definiti, collegati in modo statico a
libhealthservice
.
- Vengono definiti, crea un elemento
Se il dispositivo:
- Devi implementare le API
getStorageInfo
egetDiskStats
, fornisci le l'implementazione nelle funzioniget_storage_info
eget_disk_stats
. - Non implementare queste API, collega a
libstoragehealthdefault
in modo statico.
- Devi implementare le API
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
estoraged
di utilizzarehal_health
. - Consente a
system_server
(BatteryService
) di registrarsibatteryproperties_service
(IBatteryPropertiesRegistrar
). - Consente a
healthd
di fornirehal_health
. - Rimuove le regole che consentono a
system_server
estoraged
di chiamarehealthd
tramite binder. - Rimuove le regole che consentono a
healthd
di registrarebatteryproperties_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.