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 in modo graduale la 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 consentiva al framework Android e ad altri client attendibili, come l'HAL di un produttore di dispositivi, di leggere la temperatura corrente e le soglie di throttling e spegnimento specifiche per le norme del prodotto per ogni 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 esegue l'astrazione dell'interfaccia con i dispositivi hardware del sottosistema termico. L'interfaccia hardware include sensori di temperatura e termistori per la pelle, la batteria, la GPU, la CPU e la porta USB. La temperatura cutanea 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
raggiunge rispettivamente il livello di gravità THERMAL_STATUS_EMERGENCY
.
Figura 1. Allerte 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 viene restituito SUCCESS
, 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, da Android 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 ulteriori informazioni, consulta l'implementazione di 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 del binder,IThermalEventListener
e IThermalStatusListener
, esposte come callback. Il primo è destinato all'uso interno della piattaforma e dei produttori di dispositivi, mentre il secondo è destinato alle 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 del dispositivo
Per segnalare lo stato del sensore di temperatura e della limitazione del dispositivo per Android 10-13, i produttori di dispositivi devono implementare l'aspetto HIDL dell'HAL termico 2.0 (IThermal.hal
).
Per segnalare lo stato del sensore di temperatura e del throttling del dispositivo 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 assicurarti che ciò accada, inserisci nell'HAL termico tutti i sensori che potrebbero indicare la necessità di una mitigazione (in base alle modifiche dello stato) e segnala la gravità di eventuali azioni di mitigazione intraprese. Il valore della temperatura restituito da una lettura del sensore non deve essere necessariamente la temperatura effettiva, purché rifletta con precisione la soglia di gravità corrispondente. Ad esempio, puoi passare valori numerici diversi anziché i valori effettivi delle soglie di temperatura oppure puoi creare bande di guardia nelle specifiche delle soglie per fornire l'isteresi. Tuttavia, la gravità corrispondente a quel valore deve corrispondere a quanto necessario per la soglia in questione. Ad esempio, potresti decidere di restituire 72 °C come soglia di temperatura critica, quando la temperatura effettiva è 65 °C, e corrisponde alla gravità critica specificata. Il livello di gravità deve essere preciso 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 ascoltatori 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 di 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 ascoltatore.removeThermalStatusListener()
rimuove un ascoltatore 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 molto severa; 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 del dispositivo ha impostato tutti i componenti in modo che funzionino alla 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 ) |
Spegni immediatamente il dispositivo. 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 l'HAL termico e possono utilizzare
emul_temp
dall'interfaccia
sysfs del kernel
per simulare le variazioni di temperatura.