Con il framework Android, i produttori di dispositivi e gli sviluppatori di app possono utilizzare i dati termici per garantire un'esperienza utente (UX) coerente se un dispositivo inizia a surriscaldarsi. Ad esempio, quando un sistema è sottoposto a stress termico,
jobscheduler
i job vengono limitati e, se necessario, viene avviato un riavvio termico del framework. Le app che ricevono notifiche di stress termico
tramite un callback registrato nella
classe PowerManager
possono regolare delicatamente la propria UX.
HAL termico
Android 9 e versioni precedenti utilizzano un'interfaccia di polling definita in Thermal HAL 1.0 per ottenere le letture della temperatura. Questo HAL ha consentito al framework Android e ad altri client attendibili, come l'HAL del produttore di dispositivi, di leggere le soglie di limitazione e arresto e di limitazione della temperatura attuale e specifiche delle norme di prodotto per ciascun sensore tramite la stessa API.
Android 10 ha introdotto un sistema termico nel framework Android e una nuova versione dell'HAL, Thermal HAL 2.0, che astrae l'interfaccia ai dispositivi hardware del sottosistema termico. L'interfaccia hardware include sensori e termistori per la pelle, la batteria, la GPU, la CPU e la porta USB. La temperatura della pelle del dispositivo è il sistema più importante da monitorare per mantenere la temperatura della superficie del dispositivo entro i limiti termici specificati.
Inoltre, Thermal HAL 2.0 fornisce a più client le letture del sensore termico e i livelli di gravità associati per indicare lo stress termico. La
figura seguente mostra due messaggi di avviso dell'interfaccia utente del sistema Android. Questi messaggi vengono visualizzati quando l'interfaccia di callback IThermalEventListener
per i sensori USB_PORT
e SKIN
, rispettivamente, raggiungono il livello di gravità THERMAL_STATUS_EMERGENCY
.
Figura 1. Avvisi di surriscaldamento.
Le temperature attuali vengono recuperate per i diversi
tipi di sensori termici tramite
IThermal HAL. Ogni chiamata di funzione restituisce un valore di stato SUCCESS
o FAILURE
. Se SUCCESS
viene
restituito, il processo continua. Se viene restituito FAILURE
, a status.debugMessage
viene inviato un messaggio di errore, che deve essere leggibile.
Oltre a essere un'interfaccia di polling che restituisce le temperature attuali,
puoi utilizzare il callback
IThermalChangedCallback
(HIDL, Android da 10 a 13) o
IThermalChangedCallback
(AIDL, Android 14 e versioni successive)
con l'interfaccia di callback dei client HAL termici, come il servizio termico del framework. Ad esempio, RegisterIThermalChangedCallback
e
UnregisterIThermalChangedCallback
per registrare o annullare la registrazione degli eventi con variazione di gravità. Se la gravità termica di un determinato sensore è cambiata,
notifyThrottling
invia un callback dell'evento di throttling termico agli ascoltatori di eventi termici.
Oltre alle informazioni sul sensore termico, in getCurrentCoolingDevices
è esposto un elenco di dispositivi di raffreddamento con mitigazione. L'ordine di questo elenco è permanente, anche se un dispositivo di raffreddamento è offline. I produttori di dispositivi possono utilizzare l'elenco per raccogliere le metriche statsd
.
Per saperne di più, consulta la pagina Implementazione del riferimento.
Sebbene tu possa aggiungere le tue estensioni, non dovresti disattivare la funzione di attenuazione termica.
Servizio termico
In Android 10 e versioni successive, il servizio termico nel framework fornisce un monitoraggio costante utilizzando i vari indicatori di mitigazione di Thermal HAL 2.0 e fornisce ai propri clienti un feedback sulla gravità della limitazione. Questi client includono componenti interni e app per Android. Il servizio utilizza due interfacce di callback di binder, IThermalEventListener
e IThermalStatusListener
, esposte come callback. La versione precedente è destinata all'utilizzo da parte di produttori di dispositivi e piattaforme interne, mentre la seconda riguarda le app per Android.
Tramite le interfacce di callback, lo stato termico corrente di un dispositivo è recuperabile come valore intero compreso tra 0x00000000
(nessun throttling) e 0x00000006
(arresto del dispositivo). Solo un servizio di sistema attendibile, ad esempio un'API Android o un'API del produttore del dispositivo, può accedere alle informazioni dettagliate del sensore termico e degli eventi termici. La figura seguente fornisce un modello del flusso della procedura di mitigazione termica in Android 10 e versioni successive:
Figura 2. Flusso della procedura di mitigazione termica in Android 10 e versioni successive.
Linee guida del produttore dei dispositivi
Per segnalare lo stato del sensore di temperatura e del throttling del dispositivo per Android 10-13, i produttori di dispositivi devono implementare l'aspetto HIDL dell'HAL termico 2.0 (IThermal.hal
).
Per segnalare il sensore di temperatura del dispositivo e lo stato del throttling per Android 14, i produttori di dispositivi devono implementare l'aspetto AIDL della Thermal HAL 2.0 (IThermal.aidl
).
Tutto ciò che limita le prestazioni del dispositivo, inclusi i vincoli di alimentazione della batteria, deve essere segnalato tramite l'HAL termico. Per garantire che ciò avvenga, inserisci tutti i sensori che potrebbero indicare una necessità di mitigazione (in base ai cambiamenti dello stato) nell'HAL termico e segnala la gravità di eventuali azioni di mitigazione intraprese. Il valore della temperatura restituito dalla lettura di un sensore non deve essere la temperatura effettiva, purché rifletta accuratamente la soglia di gravità corrispondente. Ad esempio, puoi passare valori numerici diversi anziché i valori effettivi delle soglie di temperatura oppure puoi creare un intervallo di sicurezza nelle specifiche delle soglie per fornire l'isteresi. Tuttavia, la gravità corrispondente a quel valore deve corrispondere a quella necessaria per quella soglia. Ad esempio, potresti decidere di restituire 72 °C come soglia di temperatura critica, quando la temperatura effettiva è di 65 °C e corrisponde alla gravità critica che hai specificato. Il livello di gravità deve essere accurato per la migliore funzionalità del framework termico.
Per scoprire di più sui livelli di soglia nel framework e su come corrispondono alle azioni di mitigazione, consulta Utilizzare i codici di stato termico.
Utilizzare le API termiche
Le app possono aggiungere e rimuovere i listener e accedere alle informazioni sullo stato termico
tramite la
classe PowerManager
.
L'interfaccia IThermal
fornisce tutte le funzionalità necessarie, tra cui la restituzione dei valori dello stato termico. L'interfaccia del binder Thermal è incapsulata come interfaccia OnThermalStatusChangedListener
, che le app possono utilizzare per registrare o rimuovere gli ascoltatori dello stato termico.
Le API termiche di Android hanno metodi di callback e polling per consentire alle app di ricevere notifiche dei livelli di gravità termica tramite codici di stato, definiti nella classe PowerManager
. I metodi sono:
getCurrentThermalStatus()
restituisce lo stato termico corrente del dispositivo come numero intero, a meno che il dispositivo non sia sottoposto a throttling.addThermalStatusListener()
aggiunge un listener.removeThermalStatusListener()
rimuove un listener aggiunto in precedenza.
Utilizzare i codici di stato termico
I codici di stato termico si traducono in livelli di throttling specifici, che puoi utilizzare per raccogliere dati e progettare un'esperienza utente ottimale. Ad esempio, le app potrebbero ricevere uno stato 0x00000000
(THERMAL_STATUS_NONE
), che in seguito potrebbe cambiare in 0x00000001
(THERMAL_STATUS_LIGHT
). Se contrassegni lo stato 0x00000000
come t0 e poi misuri il tempo trascorso dallo stato THERMAL_STATUS_NONE
allo stato THERMAL_STATUS_LIGHT
come t1, i produttori di dispositivi possono progettare e testare strategie di mitigazione per casi d'uso specifici. La tabella seguente illustra i modi suggeriti per utilizzare i codici di stato termico:
Codice di stato termico | Descrizione e utilizzo suggerito |
---|---|
THERMAL_STATUS_NONE (0x00000000 ) |
Nessuna limitazione. Utilizza questo stato per implementare azioni di protezione, ad esempio il rilevamento dell'inizio del periodo di tempo (da t0 a t1) da THERMAL_STATUS_NONE (0 ) a THERMAL_STATUS_LIGHT (1 ). |
THERMAL_STATUS_LIGHT (0x00000001 ) |
Regolazione della velocità leggera, l'esperienza utente non è interessata. Per questa fase, utilizza una mitigazione del dispositivo delicata. Ad esempio, salta l'aumento o l'utilizzo di frequenze inefficienti, ma solo sui core grandi. |
THERMAL_STATUS_MODERATE (0x00000002 ) |
Regolazione della velocità moderata, l'esperienza utente non è molto interessata. La mitigazione termica influisce sulle attività in primo piano, pertanto le app dovrebbero ridurre immediatamente l'alimentazione. |
THERMAL_STATUS_SEVERE (0x00000003 ) |
Regolazione drastica; l'esperienza utente è notevolmente interessata. In questa fase, la mitigazione termica del dispositivo dovrebbe limitare la capacità del sistema. Questo stato potrebbe causare effetti collaterali, come scatti nella visualizzazione e jitter audio. |
THERMAL_STATUS_CRITICAL (0x00000004 ) |
La piattaforma ha fatto di tutto per ridurre il consumo di energia. Il software di mitigazione termica dei dispositivi ha posizionato tutti i componenti al massimo della capacità minima. |
THERMAL_STATUS_EMERGENCY (0x00000005 ) |
I componenti chiave della piattaforma si stanno spegnendo a causa delle condizioni termiche e la funzionalità del dispositivo è limitata. Questo codice di stato rappresenta l'ultimo avviso prima dell'arresto del dispositivo. In questo stato, alcune funzioni, come il modem e i dati mobili, vengono disattivate completamente. |
THERMAL_STATUS_SHUTDOWN (0x00000006 ) |
Arresta immediatamente. A causa della gravità di questa fase, le app potrebbero non essere in grado di ricevere questa notifica. |
I produttori di dispositivi devono superare il test VTS per HAL termico e possono utilizzare
emul_temp
dall'interfaccia
kernel sysfs
per simulare le variazioni di temperatura.