Implementa Health 2.1

Nota: l'HAL Health 2.1 è deprecato. Ti consigliamo di implementare l'HAL AIDL health� direttamente, anche sui dispositivi lanciati prima di Android 11. La documentazione per l'implementazione di Health 2.1 HAL è conservata qui come riferimento.

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 staticamente consentono a health@2.0-impl-2.1 di svolgere lo stesso lavoro di healthd, ad esempio l'esecuzione di healthd_mainloop e il polling. In init, health@2.1-service registra un'implementazione dell'interfaccia IHealth in hwservicemanager. Quando esegui l'upgrade di dispositivi con un'immagine fornitore Android 8.x o 9 e un framework Android 11, l'immagine fornitore potrebbe non fornire il servizio health@2.1. La compatibilità con le vecchie immagini dei fornitori è applicata in base al programma di ritiro.

Per garantire la compatibilità con le versioni precedenti:

1. healthd registra IHealth su hwservicemanager nonostante sia un daemon di sistema. 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 viene modificato per recuperare l'istanza "default" se disponibile, poi "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à disponibile e le immagini fornitore di Android 8.1 saranno ritirate, iHealth/backup e healthd potranno essere ritirati.

Variabili di build specifiche per la scheda per healthd

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 della scheda non possono essere definiti per i moduli di sistema. Questi valori venivano ignorati nella funzione deprecata healthd_board_init.

In health@2.1, i fornitori possono sostituire questi due valori di intervallo delle attività periodiche nella struttura healthd_config prima di passare al costruttore della classe di implementazione di Health. La classe di implementazione del controllo di integrità deve ereditare da android::hardware::health::V2_1::implementation::Health.

Implementare il servizio Health 2.1

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

Clienti sanitari

health@2.x ha i seguenti client:

• caricabatterie. L'utilizzo del codice libbatterymonitor e healthd_common è racchiuso 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 /sys/class/power_supply.

  Per motivi di sicurezza, le app non possono chiamare direttamente l'HAL di 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.

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

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

Modifiche a SELinux

L'HAL health@2.1 include le seguenti modifiche di 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 di integrità 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 di integrità.

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 criteri SELinux configurati in modo errato), potrebbero non funzionare correttamente. Pertanto, potrebbero essere necessarie 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 da interfacce del kernel mancanti, ti consigliamo di eseguire il cherry-pick di 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 health@2.1 HAL 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 della rimozione).

Requisiti per le informazioni sulla batteria

L'HAL Health 2.0 definisce una serie di requisiti per l'interfaccia HAL, ma i test VTS corrispondenti sono relativamente flessibili nella loro applicazione. In Android 11, vengono aggiunti nuovi test VTS per applicare i seguenti requisiti sui dispositivi lanciati con Android 11 e versioni successive:

• Le unità di corrente della batteria istantanea e media devono essere microampere (μA).
• Il segno della corrente della batteria istantanea e media deve essere corretto. In particolare:
  • current == 0 quando lo stato della batteria è UNKNOWN
  • current > 0 quando lo stato della batteria è CHARGING
  • current <= 0 quando lo stato della batteria è NOT_CHARGING
  • current < 0 quando lo stato della batteria è DISCHARGING
  • Non applicato quando lo stato della batteria è FULL
• Lo stato della batteria deve essere corretto in base alla connessione o meno di una fonte di 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 è scollegata.

Se utilizzi libbatterymonitor nella tua implementazione e trasmetti valori dalle interfacce del kernel, assicurati che i nodi sysfs riportino valori corretti:

• Assicurati che la corrente della batteria sia segnalata 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 ingresso nella batteria.
  • I valori devono essere espressi 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, vedi Classe di alimentazione Linux.