In Android 11, tutto il codice healthd
viene sottoposto a refactoring in libhealthloop
e libhealth2impl
, quindi modificato per implementare l'HAL Health@2.1. Queste due librerie sono collegate staticamente da health@2.0-impl-2.1
, l'implementazione passthrough di Health 2.1. Le librerie collegate staticamente consentono health@2.0-impl-2.1
di svolgere lo stesso lavoro di healthd
, come l'esecuzione healthd_mainloop
e il polling. In init, il health@2.1-service
registra un'implementazione dell'interfaccia IHealth
su hwservicemanager
. Quando si aggiornano i dispositivi con un'immagine del fornitore Android 8.x o 9 e un framework Android 11, l'immagine del fornitore potrebbe non fornire il servizio salute@2.1. La compatibilità con le versioni precedenti delle immagini dei vecchi fornitori viene applicata dal programma di deprecazione .
Per garantire la compatibilità con le versioni precedenti:
-
healthd
registraIHealth
suhwservicemanager
nonostante sia un demone di sistema.IHealth
viene aggiunto al manifesto del sistema, con il nome dell'istanza "backup". - Il framework e
storaged
comunicano conhealthd
tramitehwbinder
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
.
- Il codice client C++ utilizza la logica definita in
- Una volta che IHealth/default sarà ampiamente disponibile e le immagini dei fornitori 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 sistema/fornitore, non è possibile definire valori specifici della scheda per i moduli di sistema. Questi valori venivano sovrascritti nella funzione deprecata healthd_board_init
.
In Health@2.1, i fornitori possono sovrascrivere questi due valori di intervallo di compiti periodici nella struttura healthd_config
prima di passarli al costruttore della classe di implementazione Health. La classe di implementazione dell'integrità dovrebbe ereditare da android::hardware::health::V2_1::implementation::Health
.
Implementare il servizio Salute 2.1
Per informazioni sull'implementazione del servizio Health 2.1, vedere hardware/interfaces/health/2.1/README.md .
Clienti sanitari
Health@2.x ha i seguenti client:
- caricabatterie. L'uso di
libbatterymonitor
e del codicehealthd_common
è racchiuso inhealth@2.0-impl
. - recupero. Il collegamento a
libbatterymonitor
è racchiuso inhealth@2.0-impl
. Tutte le chiamate aBatteryMonitor
vengono sostituite dalle chiamate alla classe di implementazioneHealth
. Gestione batteria.
BatteryManager.queryProperty(int id)
era l'unico client diIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
è stato fornito dahealthd
e letto direttamente/sys/class/power_supply
.Come considerazione di sicurezza, le app non possono chiamare direttamente l'HAL di integrità. In Android 9 e versioni successive, il servizio di associazione
IBatteryPropertiesRegistrar
è fornito daBatteryService
anziché dahealthd
.BatteryService
delega la chiamata all'HAL di integrità per recuperare le informazioni richieste.BatteriaService. In Android 9 e versioni successive,
BatteryService
utilizzaHealthServiceWrapper
per determinare se utilizzare l'istanza del servizio sanitario predefinito dalvendor
o utilizzare l'istanza del servizio sanitario di backup dahealthd
.BatteryService
ascolta quindi gli eventi di integrità tramiteIHealth.registerCallback
.Stoccaggio. In Android 9 e versioni successive,
storaged
utilizzalibhealthhalutils
per determinare se utilizzare l'istanza del servizio sanitario predefinito dalvendor
o utilizzare l'istanza del servizio sanitario di backup dahealthd
.storaged
quindi ascolta gli eventi di integrità tramiteIHealth.registerCallback
e recupera le informazioni di archiviazione.
SELinux cambia
L'HAL Health@2.1 include le seguenti modifiche SELinux nella piattaforma:
- Aggiunge
android.hardware.health@2.1-service
afile_contexts
.
Per i dispositivi con la propria implementazione, potrebbero essere necessarie alcune modifiche al fornitore SELinux. 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 demone healthd
e l'implementazione predefinita android.hardware.health@2.0-impl-2.1
accedono alle seguenti interfacce del kernel per recuperare informazioni sulla batteria:
-
/sys/class/power_supply/*/capacity_level
(aggiunto in Health 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
(aggiunto in Health 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
(aggiunto in Health 2.1) -
/sys/class/power_supply/*/type
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
Qualsiasi implementazione HAL di integrità specifica del dispositivo che utilizza libbatterymonitor
accede a queste interfacce del kernel per impostazione predefinita, a meno che non venga sovrascritta nel costruttore della classe di implementazione dell'integrità.
Se questi file mancano o sono inaccessibili 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 della policy SELinux configurata in modo errato), potrebbero non funzionare correttamente. Pertanto potrebbero essere necessarie ulteriori modifiche SELinux specifiche del fornitore anche se viene utilizzata l'implementazione predefinita.
Alcune interfacce del kernel utilizzate in Health 2.1, come /sys/class/power_supply/*/capacity_level
e /sys/class/power_supply/*/time_to_full_now
, potrebbero essere facoltative. Tuttavia, per evitare comportamenti errati del framework derivanti dalla mancanza di interfacce kernel, si consiglia di selezionare CL 1398913 prima di creare il servizio Health HAL 2.1.
Test
Android 11 include nuovi test VTS scritti appositamente per l'HAL Health@2.1. Se un dispositivo dichiara HAL Health@2.1 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
L'HAL Health 2.0 stabilisce una serie di requisiti sull'interfaccia HAL, ma i test VTS corrispondenti sono relativamente rilassati nel farli rispettare. In Android 11 vengono aggiunti nuovi test VTS per applicare i seguenti requisiti sui dispositivi avviati con Android 11 e versioni successive:
- Le unità della corrente innata e media della batteria devono essere microampere (μA).
- Il segno della corrente istantanea e media della batteria deve essere corretto. Nello specifico:
- corrente == 0 quando lo stato della batteria è
UNKNOWN
- corrente > 0 quando lo stato della batteria è
CHARGING
- corrente <= 0 quando lo stato della batteria è
NOT_CHARGING
- corrente < 0 quando lo stato della batteria è
DISCHARGING
- Non applicato quando lo stato della batteria è
FULL
- corrente == 0 quando lo stato della batteria è
- Lo stato della batteria deve essere corretto rispetto al fatto che una fonte di alimentazione sia collegata o meno. Nello specifico:
- lo stato della batteria deve essere tra
CHARGING
,NOT_CHARGING
oFULL
se e solo se è collegata una fonte di alimentazione; - lo stato della batteria deve essere
DISCHARGING
se e solo se una fonte di alimentazione è scollegata.
- lo stato della batteria deve essere tra
Se utilizzi libbatterymonitor
nella tua implementazione e passi attraverso valori dalle interfacce del kernel, assicurati che i nodi sysfs riportino valori corretti:
- Assicurarsi che la corrente della batteria sia riportata con il segno e le unità corretti. Ciò 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 ingresso nella batteria.
- I valori dovrebbero essere in microampere (μA).
-
- Assicurarsi che la tensione della batteria sia riportata in microvolt (μV). Ciò include i 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). Vedi @1.0::HealthInfo .
-
Per i dettagli, vedere Classe di alimentazione Linux .