Implementa l'integrità 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 in modo statico da health@2.0-impl-2.1, l'implementazione passthrough di Health 2.1. Le librerie collegate in modo statico consentono a health@2.0-impl-2.1 di svolgere le stesse attività di healthd, ad esempio eseguire healthd_mainloop e eseguire polling. In init, health@2.1-service registra un'implementazione dell'interfaccia IHealth in hwservicemanager. Quando esegui l'upgrade dei 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. La compatibilità con le vecchie immagini dei fornitori è impostata dalla pianificazione del ritiro.

Per garantire la compatibilità con le versioni precedenti:

  1. healthd registra IHealth in hwservicemanager nonostante sia un daemon di sistema. IHealth viene aggiunto al file 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 viene modificato per recuperare l'istanza "predefinita", se disponibile, quindi "di riserva".
    • Il codice client C++ utilizza la logica definita in libhealthhalutils.
    • Il codice client Java utilizza la logica definita in HealthServiceWrapper.
  4. Una volta che IHealth/default sarà ampiamente disponibile e le immagini dei fornitori di Android 8.1 verranno ritirate, IHealth/backup e healthd potranno essere deprecati. Per maggiori dettagli, consulta Ritiro di health@1.0.

Variabili di compilazione specifiche per la scheda per healthd

BOARD_PERIODIC_CHORES_INTERVAL_* sono variabili specifiche del consiglio utilizzate per creare healthd. Nell'ambito della suddivisione della build del sistema/del fornitore, non è possibile definire valori specifici della scheda 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 di questi due valori degli intervalli di operazioni di routine nello struct healthd_config prima di passare al costruttore della classe di implementazione dell'integrità. La classe di implementazione dell'integrità deve ereditare da android::hardware::health::V2_1::implementation::Health.

Implementa il servizio Health 2.1

Per informazioni sull'implementazione del servizio Health 2.1, consulta hardware/interfaces/health/2.1/README.md.

Client di salute

health@2.x ha i seguenti client:

  • caricabatterie. L'utilizzo del codice libbatterymonitor e healthd_common è incapsulato in health@2.0-impl.
  • recovery. Il collegamento a libbatterymonitor è racchiuso in health@2.0-impl. Tutte le chiamate a BatteryMonitor vengono sostituite da chiamate alla classe di implementazione Health.

  • BatteryManager. BatteryManager.queryProperty(int id) era l'unico cliente di IBatteryPropertiesRegistrar.getProperty. IBatteryPropertiesRegistrar.getProperty è stato fornito da healthd e letto direttamente da /sys/class/power_supply.

    Per motivi di sicurezza, le app non sono autorizzate a chiamare direttamente l'HAL per la salute. In Android 9 e versioni successive, il servizio binder IBatteryPropertiesRegistrar è fornito da BatteryService anziché da healthd. BatteryService delega la chiamata all'HAL per la salute per recuperare le informazioni richieste.

  • ServizioBatteria. In Android 9 e versioni successive, BatteryService utilizza HealthServiceWrapper per determinare se utilizzare l'istanza del servizio di integrità predefinita di vendor o l'istanza del servizio di integrità backup di healthd. BatteryService rimane in ascolto degli eventi relativi alla salute tramite IHealth.registerCallback.

  • Storaged. In Android 9 e versioni successive, storaged utilizza libhealthhalutils per determinare se utilizzare l'istanza del servizio di integrità predefinita di vendor o l'istanza del servizio di integrità backup di healthd. storaged quindi ascolta gli eventi di integrità tramite IHealth.registerCallback e recupera le informazioni di archiviazione.

Modifiche a SELinux

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 implementazione propria, potrebbero essere necessarie alcune modifiche SELinux del fornitore. 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 recuperare le informazioni sulla batteria:

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

Qualsiasi implementazione HAL per la salute specifica del dispositivo che utilizza libbatterymonitor accede a queste interfacce del kernel per impostazione predefinita, a meno che non venga sostituita nel costruttore della classe di implementazione della salute.

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 funzionare correttamente. Pertanto, potrebbero essere necessarie modifiche SELinux aggiuntive specifiche del fornitore anche se viene utilizzata l'implementazione predefinita.

Alcune interfacce del kernel utilizzate in Salute 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 dovuti a interfacce del kernel mancanti, è consigliabile scegliere manualmente CL 1398913 prima di creare il servizio Health HAL 2.1.

Test

Android 11 include nuovi test VTS scritti appositamente per health@2.1 HAL. Se un dispositivo dichiara health@2.1 HAL nel relativo file manifest, deve superare i test VTS corrispondenti. I test vengono scritti sia per l'istanza predefinita (per assicurarsi che il dispositivo implementi correttamente l'HAL) sia per l'istanza di backup (per assicurarsi che healthd continui a funzionare correttamente prima di essere rimosso).

Requisiti relativi alle informazioni sulla batteria

L'HAL di Salute 2.0 definisce un insieme di requisiti per l'interfaccia HAL, ma i test VTS corrispondenti sono relativamente rilassati per quanto riguarda l'applicazione. In Android 11 sono stati aggiunti nuovi test VTS per applicare i seguenti requisiti ai dispositivi lanciati con Android 11 e versioni successive:

  • Le unità di corrente intata e della corrente media della batteria devono essere microampere (μA).
  • Il segno dell'intensità di corrente della batteria istantanea e media deve essere corretto. In particolare:
    • current == 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 in base al fatto che sia o meno collegata un'alimentazione. In particolare:
    • 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 una fonte di alimentazione è disconnessa.

Se utilizzi libbatterymonitor nell'implementazione e passi i valori dalle interfacce del kernel, assicurati che i nodi sysfs riportino valori corretti:

  • Assicurati che l'intensità di corrente della batteria sia indicata con il segno e le unità corretti. Sono inclusi 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 microampere (μA).
  • Assicurati che la tensione della batteria sia indicata in microvolt (μV). Sono inclusi 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 maggiori dettagli, consulta la classe di alimentazione Linux.