Implementazione della salute 2.1

In Android 11, tutti healthd codice viene riscritta in libhealthloop e libhealth2impl , poi modificato per attuare il HAL health@2.1. Questi due librerie sono collegate staticamente dal health@2.0-impl-2.1 , il passthrough implementazione di salute 2.1. Le librerie collegate staticamente permettono health@2.0-impl-2.1 a fare lo stesso lavoro di healthd , come la corsa healthd_mainloop e sondaggi. In init, il health@2.1-service registra un'implementazione dell'interfaccia IHealth a 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 health@2.1. Compatibilità con immagini vendor vecchi viene applicata dal programma deprecazione .

Per garantire la retrocompatibilità:

  1. healthd registra IHealth a hwservicemanager pur essendo un demone di sistema. IHealth viene aggiunto il manifesto del sistema, con il nome di istanza "backup".
  2. Il quadro e storaged comunicano con healthd via hwbinder invece di binder .
  3. Il codice per la struttura e storaged vengono modificati per andare a prendere l'istanza di "default", se disponibile, quindi "backup".
    • C ++ codice client utilizza la logica definita in libhealthhalutils .
    • Java codice client utilizza la logica definita in HealthServiceWrapper .
  4. Dopo iHealth / default è ampiamente disponibile e immagini Android 8.1 vendor sono deprecati, iHealth / backup e healthd può essere deprecato. Per maggiori dettagli, vedere deprecando health@1.0 .

Variabili di build specifiche della scheda per healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sono variabili specifiche pensione usato per costruire healthd . Come parte del sistema / fornitore accumulo divisione, valori bordo-specifici non possono essere definiti per moduli di sistema. Questi valori utilizzati per essere sovrascritte nella funzione deprecato healthd_board_init .

In health@2.1, i fornitori possono ignorare queste due faccende periodici valori di intervallo nella healthd_config struct prima di passare al costruttore classe di implementazione della salute. La classe di implementazione della salute dovrebbe ereditare da android::hardware::health::V2_1::implementation::Health .

Implementazione del servizio Salute 2.1

Per informazioni sull'implementazione del servizio sanitario 2.1, vedere l'hardware / interfacce / salute / 2.1 / README.md .

Clienti della salute

health@2.x ha i seguenti client:

  • caricabatterie. L'uso di libbatterymonitor e healthd_common codice viene avvolto in health@2.0-impl .
  • il recupero. Il collegamento con libbatterymonitor è avvolto in health@2.0-impl . Tutte le chiamate verso BatteryMonitor sono sostituiti da chiamate in arrivo sulla Health classe di implementazione.
  • BatteryManager. BatteryManager.queryProperty(int id) è stato l'unico cliente della IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty è stato fornito da healthd e leggere direttamente /sys/class/power_supply .

    Per motivi di sicurezza, le app non possono chiamare direttamente l'HAL dell'integrità. In Android 9 e superiore, il servizio legante IBatteryPropertiesRegistrar è fornito dalla BatteryService anziché healthd . BatteryService delega la chiamata al HAL salute per recuperare le informazioni richieste.

  • BatteryService. In Android 9 e versioni successive, BatteryService utilizza HealthServiceWrapper per determinare se utilizzare l'istanza del servizio sanitario di default da vendor o di utilizzare l'istanza del servizio sanitario di backup da healthd . BatteryService ascolta poi per eventi sanitari tramite IHealth.registerCallback .

  • Memorizzabile. In Android 9 e versioni successive, storaged usi libhealthhalutils per determinare se utilizzare l'istanza del servizio sanitario di default da vendor o di utilizzare l'istanza del servizio sanitario di backup da healthd . storaged poi intercetta gli eventi sanitari attraverso IHealth.registerCallback e recupera le informazioni di memorizzazione.

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 healthd demone e l'implementazione di default android.hardware.health@2.0-impl-2.1 accedere alle seguenti interfacce del kernel per recuperare informazioni sulla batteria:

  • /sys/class/power_supply/*/capacity_level (aggiunto in materia di 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 (aggiunto in materia di 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 (aggiunto in materia di salute 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Qualsiasi implementazione HAL salute specifico del dispositivo che usi libbatterymonitor accede a queste interfacce kernel di default, a meno che sovrascritto nel costruttore della classe implementazione di salute.

Se questi file sono mancanti o sono inaccessibili da healthd o dal servizio di default (ad esempio, il file è un link simbolico a una cartella vendor-specifico che nega l'accesso a causa della politica di SELinux mal configurato), essi potrebbero non funzionare correttamente. Pertanto, potrebbero essere necessarie ulteriori modifiche a SELinux specifiche del fornitore anche se viene utilizzata l'implementazione predefinita.

Alcune interfacce kernel utilizzati in Health 2.1, come ad esempio /sys/class/power_supply/*/capacity_level e /sys/class/power_supply/*/time_to_full_now , possono essere opzionali. Tuttavia, per evitare comportamenti scorretti quadro che derivi dalla mancanza interfacce del kernel, si consiglia di cherry-pick CL 1.398.913 prima di costruire il 2.1 servizio sanitario HAL.

test

Android 11 include nuove VTS prove scritte appositamente per l'HAL health@2.1. Se un dispositivo dichiara health@2.1 HAL nel manifest del dispositivo, deve superare i corrispondenti test VTS. I test vengono scritti sia per l'istanza predefinita (per assicurare che gli attrezzi del dispositivo della HAL correttamente) e l'istanza di backup (per garantire che healthd continua correttamente funzione prima di essere rimosso).

Requisiti per le informazioni sulla batteria

L'HAL salute 2.0 stabilisce una serie di requisiti sull'interfaccia HAL, ma i corrispondenti test VTS sono relativamente rilassati nell'applicarli. In Android 11, vengono aggiunti nuovi test VTS per applicare i seguenti requisiti sui dispositivi avviati con Android 11 e versioni successive:

  • Le unità di corrente della batteria istantanea e media devono essere microampere (μA).
  • Il segno della corrente di batteria istantanea e media 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 forzate quando lo stato della batteria è FULL
  • Lo stato della batteria deve essere corretto rispetto al collegamento o meno di una fonte di alimentazione. Nello specifico:
    • stato della batteria deve essere uno dei CHARGING , NOT_CHARGING o FULL se e solo se è collegata una sorgente di alimentazione;
    • stato della batteria deve essere DISCHARGING se e solo se una sorgente di alimentazione è scollegato.

Se si utilizza libbatterymonitor nell'implementazione e passa attraverso i valori da interfacce del kernel, assicurarsi che i nodi stanno segnalando sysfs 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
    • Si noti che le divide implementazione di default HAL voltage_now dal 1000 e valori report in millivolt (mV). Vedere @ 1.0 :: HealthInfo .

Per dettagli, vedere Classe alimentazione Linux .