In Android 11, viene eseguito il refactoring di tutto il codice healthd
in
libhealthloop
e libhealth2impl
, quindi modificati per implementare l'elemento health@2.1
HAL Queste due librerie sono collegate in modo statico da health@2.0-impl-2.1
,
l’implementazione passthrough della sanità 2.1. Le librerie collegate in modo statico
abilita health@2.0-impl-2.1
a svolgere le stesse operazioni di healthd
, ad esempio eseguire
healthd_mainloop
e sondaggio. In init, health@2.1-service
registra una
implementazione dell'interfaccia da IHealth
a hwservicemanager
. Durante l'upgrade
dispositivi con Android 8.x o 9
un'immagine del fornitore e un framework Android 11,
l'immagine del fornitore potrebbe non fornire il servizio health@2.1. Indietro
la compatibilità con le immagini dei vecchi fornitori viene applicata
pianificazione del ritiro.
Per garantire la compatibilità con le versioni precedenti:
healthd
registraIHealth
inhwservicemanager
nonostante sia un sistema daemon.IHealth
viene aggiunto al manifest di sistema, con il nome dell'istanza "backup".- Il framework e
storaged
comunicano conhealthd
tramitehwbinder
anzichébinder
. - Il codice per il framework e
storaged
vengono modificati per recuperare l'istanza "predefinito" se disponibile, seleziona "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 i dettagli, vedi 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/fornitore, i valori specifici del consiglio di amministrazione
non può essere definito per i moduli di sistema. In precedenza questi valori venivano sostituiti
nella funzione deprecata healthd_board_init
.
In health@2.1, i fornitori possono eseguire l'override
questi due valori dell'intervallo di faccende periodiche nello struct healthd_config
prima
passando al costruttore della classe di implementazione
dell'integrità. L'integrità
di implementazione deve ereditare
android::hardware::health::V2_1::implementation::Health
.
Implementare il servizio Salute 2.1
Per informazioni sull'implementazione del servizio Health 2.1, vedi hardware/interfaces/health/2.1/README.md.
Client sanitari
health@2.x ha i seguenti clienti:
- caricatore. L'utilizzo del codice
libbatterymonitor
ehealthd_common
è aggregato inhealth@2.0-impl
. - di recupero. Il collegamento a
libbatterymonitor
è aggregatohealth@2.0-impl
. Tutte le chiamate aBatteryMonitor
vengono sostituite da chiamate a la classe di implementazioneHealth
. BatteryManager.
BatteryManager.queryProperty(int id)
è stato l'unico cliente diIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
è stato fornito dahealthd
e leggere direttamente/sys/class/power_supply
.Per motivi di sicurezza, le app non sono autorizzate a chiamare l'HAL per la salute strato Add. In Android 9 e versioni successive, il servizio
IBatteryPropertiesRegistrar
è fornito daBatteryService
anzichéhealthd
.BatteryService
delega la chiamata all'HAL per l'integrità per recuperare le informazioni richieste.ServizioBatteria. In Android 9 e versioni successive,
BatteryService
utilizzaHealthServiceWrapper
per determinare se utilizzare predefinita per l'istanza del servizio di integrità davendor
o per utilizzare il servizio di backup di servizio sanitario dihealthd
.BatteryService
quindi ascolta eventi di salute fino al giornoIHealth.registerCallback
.Archiviazione. In Android 9 e versioni successive,
storaged
utilizzalibhealthhalutils
per determinare se utilizzare predefinita per l'istanza del servizio di integrità davendor
o per utilizzare il servizio di backup di servizio sanitario dihealthd
.storaged
poi ascolta gli eventi relativi alla salute tramiteIHealth.registerCallback
e recupera informazioni sull'archiviazione.
Modifiche a SELinux
L'HAL health@2.1 include i seguenti cambiamenti di SELinux nella piattaforma:
- Aggiunge
android.hardware.health@2.1-service
afile_contexts
.
Per i dispositivi con una propria implementazione, alcune modifiche SELinux del fornitore potrebbero essere necessaria. Esempio:
# 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
Il daemon healthd
e l'implementazione predefinita
android.hardware.health@2.0-impl-2.1
accedono alle seguenti interfacce del kernel per
recupera informazioni sulla batteria:
/sys/class/power_supply/*/capacity_level
(aggiunta in Salute 2.1)/sys/class/power_supply/*/capacity
/sys/class/power_supply/*/charge_counter
/sys/class/power_supply/*/charge_full
/sys/class/power_supply/*/charge_full_design
(aggiunta in Salute 2.1)/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
/sys/class/power_supply/*/cycle_count
/sys/class/power_supply/*/health
/sys/class/power_supply/*/online
/sys/class/power_supply/*/present
/sys/class/power_supply/*/status
/sys/class/power_supply/*/technology
/sys/class/power_supply/*/temp
/sys/class/power_supply/*/time_to_full_now
(aggiunta in Salute 2.1)/sys/class/power_supply/*/type
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
Qualsiasi implementazione dell'HAL per l'integrità specifica del dispositivo che utilizza libbatterymonitor
accede a queste interfacce del kernel per impostazione predefinita, a meno che non venga sostituito nell'integrità
della classe di implementazione.
Se questi file non sono presenti o non sono accessibili da healthd
o dal
servizio predefinito (ad esempio, il file è un collegamento simbolico a una cartella specifica del fornitore
che nega l'accesso a causa di un criterio SELinux configurato in modo errato), potrebbero non
funzionino correttamente. Pertanto, ulteriori modifiche SELinux specifiche del fornitore
necessaria anche se viene utilizzata
l'implementazione predefinita.
Alcune interfacce del kernel usate in Health 2.1, come
/sys/class/power_supply/*/capacity_level
e
/sys/class/power_supply/*/time_to_full_now
, potrebbe essere facoltativo. Tuttavia, per
evitare comportamenti del framework non corretti derivanti
dall'assenza di interfacce del kernel,
è consigliabile scegliere
CL 1398913
prima di creare il servizio Health HAL 2.1.
Test
Android 11 include nuove
Test VTS
e scritte appositamente per health@2.1 HAL. Se un dispositivo dichiara
health@2.1 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
L'HAL 2.0 stabilisce una serie di requisiti sull'interfaccia dell'HAL, ma i test VTS corrispondenti sono relativamente semplici nell'applicazione delle norme. In Android 11, vengono aggiunti nuovi test VTS per applicare i seguenti requisiti per i dispositivi che vengono lanciati con Android 11 e successive:
- Le unità di corrente intata e della corrente media della batteria devono essere microampere (μA).
- I segni della corrente di batteria istantanea e media devono essere corretti.
Nello specifico:
- attuale == 0 quando lo stato della batteria è
UNKNOWN
- attuale > 0 quando lo stato della batteria è
CHARGING
- attuale <= 0 quando lo stato della batteria è
NOT_CHARGING
- attuale < 0 quando lo stato della batteria è
DISCHARGING
- Non applicata quando lo stato della batteria è
FULL
- attuale == 0 quando lo stato della batteria è
- Lo stato della batteria deve essere corretto a seconda del fatto che la fonte di alimentazione
connesso. Nello specifico:
- lo stato della batteria deve essere
CHARGING
,NOT_CHARGING
oFULL
se e solo se è collegata una fonte di alimentazione; - lo stato della batteria deve essere
DISCHARGING
se e solo se è presente una fonte di alimentazione disconnesso.
- lo stato della batteria deve essere
Se utilizzi libbatterymonitor
nella tua implementazione e trasmetti i valori
dalle interfacce del kernel, assicurati che i nodi sysfs riportino valori corretti:
- Assicurati che la corrente della batteria sia indicata con il simbolo e le unità corretti. Questo
include i seguenti nodi sysfs:
/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
- I valori positivi indicano la corrente in entrata nella batteria.
- I valori devono essere in microamp (μA).
- Assicurati che la tensione della batteria sia riportata in microvolt (μV). È incluso il
seguenti nodi sysfs:
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
- Tieni presente che l'implementazione HAL predefinita divide
voltage_now
per 1000 e riporta i valori in millivolt (mV). Consulta @1.0::HealthInfo.
Per maggiori dettagli, vedi Classe di alimentazione Linux.