Questa pagina è stata tradotta dall'API Cloud Translation.

Implementare la sanità 2.1

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 registra IHealth su hwservicemanager nonostante sia un demone di sistema. IHealth viene aggiunto al manifesto del sistema, con il nome dell'istanza "backup".
Il 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 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 .

Implementazione del 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 codice healthd_common è racchiuso in health@2.0-impl .
recupero . Il collegamento a libbatterymonitor è racchiuso in health@2.0-impl . Tutte le chiamate a BatteryMonitor vengono sostituite dalle chiamate alla classe di implementazione Health .
Gestore batteria . BatteryManager.queryProperty(int id) era l'unico client di IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty è stato fornito da healthd 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 da BatteryService anziché da healthd . BatteryService delega la chiamata all'HAL di integrità per recuperare le informazioni richieste.
Servizio batteria . In Android 9 e versioni successive, BatteryService utilizza HealthServiceWrapper per determinare se utilizzare l'istanza del servizio sanitario predefinito dal vendor o utilizzare l'istanza del servizio sanitario di backup da healthd . BatteryService ascolta quindi gli eventi di integrità tramite IHealth.registerCallback .
Archiviazione . In Android 9 e versioni successive, storaged utilizza libhealthhalutils per determinare se utilizzare l'istanza del servizio sanitario predefinito dal vendor o utilizzare l'istanza del servizio sanitario di backup da healthd . storaged quindi ascolta gli eventi di integrità tramite IHealth.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 a file_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 politica 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 HAL 2.1 di integrità.

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
Lo stato della batteria deve essere corretto rispetto al fatto che sia collegata o meno una fonte di alimentazione. Nello specifico:
- lo stato della batteria deve essere tra CHARGING , NOT_CHARGING o FULL 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.

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 .