Implementa l'integrità 2.1

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:

  1. healthd registra IHealth in hwservicemanager nonostante sia un sistema daemon. IHealth viene aggiunto al manifest di sistema, con il nome dell'istanza "backup".
  2. Il framework e storaged comunicano con healthd tramite hwbinder anziché binder.
  3. 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.
  4. 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 e healthd_common è aggregato in health@2.0-impl.
  • di recupero. Il collegamento a libbatterymonitor è aggregato health@2.0-impl. Tutte le chiamate a BatteryMonitor vengono sostituite da chiamate a la classe di implementazione Health.

  • BatteryManager. BatteryManager.queryProperty(int id) è stato l'unico cliente di IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty è stato fornito da healthd 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 da BatteryService anziché healthd. BatteryService delega la chiamata all'HAL per l'integrità per recuperare le informazioni richieste.

  • ServizioBatteria. In Android 9 e versioni successive, BatteryService utilizza HealthServiceWrapper per determinare se utilizzare predefinita per l'istanza del servizio di integrità da vendor o per utilizzare il servizio di backup di servizio sanitario di healthd. BatteryService quindi ascolta eventi di salute fino al giorno IHealth.registerCallback.

  • Archiviazione. In Android 9 e versioni successive, storaged utilizza libhealthhalutils per determinare se utilizzare predefinita per l'istanza del servizio di integrità da vendor o per utilizzare il servizio di backup di servizio sanitario di healthd. storaged poi ascolta gli eventi relativi alla salute tramite IHealth.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 a file_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
  • 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 o FULL 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.

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.