Statistiche di potenza HAL

L'alimentazione del sottosistema del dispositivo viene spesso misurata e registrata in un ambiente di laboratorio per varie condizioni stazionarie, ad esempio quando lo schermo è acceso o il dispositivo è in uno stato di inattività. Ciò funziona per i sottosistemi con un assorbimento di potenza costante o in condizioni facilmente misurabili in ambienti di laboratorio, ma non per determinati casi d'uso, come quando uno schermo visualizza un video.

IPower.hal 1.0 fornisce un'interfaccia per trasmettere suggerimenti di alimentazione e riportare dati cumulativi sui parametri dello stato di sospensione del sottosistema. In Android 10 e versioni successive, la funzione di reporting statistico cumulativo risiede nelle API di raccolta delle statistiche di alimentazione IPowerStats.hal e fornisce un modo per recuperare i dati sull'utilizzo energetico del dispositivo. Questo sostituisce la parte di raccolta statistiche cumulativa dell'interfaccia IPower.hal , per una più chiara separazione delle funzionalità.

Le letture del servizio IPowerStats non sono periodiche. Si verificano in momenti chiave, ad esempio quando si verifica un calo della batteria dell'1%. Le letture sono meno frequenti quando il consumo della batteria è basso e più frequenti quando è alto. I dati possono essere rinviati ai server e possono essere utilizzati nelle segnalazioni di bug per l'analisi e il triage. Ciò supporta gli sforzi continui per ridurre il consumo energetico e aumentare la durata della batteria.

IPower.hal e IPowerStats.hal

Entrambe le interfacce IPower.hal e IPowerStats.hal sono disponibili su Android 10, ma la funzionalità di raccolta delle statistiche IPower.hal è disponibile solo dall'interfaccia IPowerStats.hal . La funzionalità IPowerStats.hal include API per acquisire e utilizzare i dati raccolti dalle misurazioni di potenza sul dispositivo per i dispositivi supportati:

  • Esegue misurazioni energetiche a livello di binario sia per i client a bassa frequenza ( getRailInfo ) che ad alta frequenza ( streamEnergyData ) e segnala l'energia accumulata dall'avvio.
  • Riporta le informazioni relative a ciascuna PowerEntity supportata per la quale sono disponibili dati. Una PowerEntity è un sottosistema della piattaforma, una periferica o un dominio di alimentazione che incide sul consumo energetico totale del dispositivo.
  • Riporta l'insieme di stati delle entità di alimentazione ( getPowerEntityStateInfo ) per i quali le entità specificate forniscono dati di residenza, quindi segnala i dati accumulati per ciascuna PowerEntity specificata.

Le API IPowerStats.hal sono utilizzate dai seguenti client:

  • Statsd , per raccogliere parametri di consumo energetico per binario.
  • Perfetto , per correlare il consumo energetico con l'attività della CPU.
  • Batterystats , per migliorare l'attribuzione della batteria utilizzando i dati misurati anziché stimare il consumo della batteria da costanti predefinite in power_profile.xml.

Con Android 10 e versioni successive, un produttore di dispositivi può scegliere tra le funzioni IPower.hal e IPowerStats.hal , ma tutti i client devono ricorrere a IPower.hal se IPowerStats.hal non è implementato.

Opzioni di implementazione di IPowerStats.hal

Solo le funzioni IPower.hal sono disponibili da Android 7 ad Android 9. I dispositivi aggiornati ad Android 10 devono disporre di un sottosistema di monitoraggio dell'energia hardware o di altri mezzi disponibili per monitorare e registrare le statistiche sull'energia. Alcuni SoC raccolgono statistiche sul consumo energetico per te oppure puoi ottenere informazioni sulla residenza dello stato dell'entità energetica tramite software. L'hardware di monitoraggio energetico è necessario solo per supportare getRailInfo() , getEnergyData() e streamEnergyData() .

Se implementi IPowerStats.hal senza hardware di monitoraggio energetico, getRailInfo(), getEnergyData() e streamEnergyData() restituiscono NOT_SUPPORTED . Allo stesso modo, getPowerEntityInfo(), getPowerEntityStateInfo() e getPowerEntityStateResidencyData() possono anche restituire NOT_SUPPORTED se non è previsto l'utilizzo.

Esempi di dati restituiti dalle API di monitoraggio ferroviario includono

  • La barra di alimentazione del display ha consumato X µW.
  • La barra di alimentazione del modem ha consumato Y µW.

Esempi di dati restituiti dalle API dello stato di sospensione del sottosistema includono

  • Il modem è rimasto inattivo per X ms.
  • Il SoC è rimasto in stato di collasso dell'alimentazione per Y ms.
  • La GPU era in stato di sospensione per Z ms.

Utilizzare un sottosistema di monitoraggio dell'alimentazione hardware

Se il progetto del tuo dispositivo prevede un sottosistema di monitoraggio dell'alimentazione hardware, implementa IPowerStats.hal creando un singolo nodo sysfs da cui PowerStats.hal può analizzare i dati o creando una raccolta di chiamate di sistema di tipo ioctl .

È necessario implementare il driver del kernel in modo da impedire l'overflow dell'accumulatore. L'algoritmo utilizzato dipende dalla progettazione esclusiva del sottosistema di monitoraggio della potenza hardware, che deve fornire misurazioni della tensione e della corrente del bus sia istantanee che medie. Il driver del kernel deve acquisire questi dati in modo da non svuotare gli accumulatori di energia e deve mantenere i dati di energia accumulati per ciascuna sottorotaia dall'avvio, sotto forma di una variabile a 64 bit che viene incrementata con la lettura dell'energia da ogni query dell'accumulatore.

Le statistiche per un determinato componente (o, facoltativamente, più componenti) devono trovarsi in un singolo nodo. Sebbene questo non sia un uso convenzionale di sysfs (che normalmente limita ciascun nodo a un singolo valore), garantisce che tutti i dati siano coerenti.

Guida alla progettazione

  • Mantieni la latenza bassa (1 msec, massimo) durante la lettura dal nodo sysfs o l'effettuazione di chiamate di sistema.
  • Assicurati che la funzionalità di supporto delle statistiche non aumenti in modo misurabile il consumo di energia:
    • Non aumentare le attivazioni del punto di accesso (AP) e/o del sottosistema per tenere traccia di parametri come il tempo trascorso in modalità di sospensione.
    • Trasferisci le statistiche tra il processore dell'app e il firmware in modo opportunistico con altro traffico quando possibile.
  • Se necessario, il sottosistema può utilizzare le seguenti funzioni del driver:
    • Memorizzazione interna dei dati nella cache per evitare latenza/risvegli a scapito di dati leggermente obsoleti.
    • Esecuzione di estrapolazione quando il sottosistema è inattivo, per fornire il tempo di inattività aggiornato senza riattivare il sottosistema.

Scegli componenti, sottosistemi e statistiche

Quando si scelgono i componenti o i sottosistemi da cui raccogliere i dati IPowerStats.hal , selezionare qualsiasi cosa sul dispositivo che consumi una corrente significativa (5 mA o più) o che supporti più modalità di consumo energetico, come le seguenti:

  • Sottosistemi SoC individuali.
  • Sottosistemi parzialmente o completamente esterni al SoC, come WiFi, processore di immagini o processore di sicurezza.
  • Periferiche come LED ad alta potenza e telecamere.
  • Domini di potenza che utilizzano modalità diverse (come il dominio di potenza per il SoC nel suo complesso).

Personalizzazione

Questa funzionalità opzionale è suscettibile di personalizzazione. Progetta casi d'uso e personalizza il tuo utilizzo:

  • Decidi quali binari misurare e con quale frequenza misurarli.
  • Decidi quando leggere i dati e come interpretarli.
  • Decidi quale azione intraprendere e quando intraprenderla, in base ai tuoi dati.

Validazione

I test VTS garantiscono che i requisiti Android siano soddisfatti. I commenti in IPowerStats.hal vengono utilizzati per verificare che un dispositivo sia conforme.

Ad esempio, se chiami getRailInfo() e non restituisce nulla, il test VTS fallisce, perché non hai ricevuto informazioni sui binari monitorati o uno stato restituito di SUCCESS . Allo stesso modo, se hai ricevuto informazioni ferroviarie, ma erano accompagnate da una risposta NON_SUPPORTED o FILE_SYSTEM_ERROR , anche questo è un errore. Il VTS verifica che le specifiche del produttore del dispositivo siano rispettate nel file HAL, utilizzando i requisiti nei commenti IPower.hal e IPowerStats.hal. Di seguito è riportato un esempio di commenti utilizzati nei test VTS:

/**
* Rail information:
* Reports information related to the rails being monitored.
*
* @return rails Information about monitored rails.
* @return status SUCCESS on success or NOT_SUPPORTED if
* feature is not enabled or FILESYSTEM_ERROR on filesystem nodes
* access error.
*/
getRailInfo()
generates(vec<e;RailInfo>e; rails, Status status);