Mit dem Android-Framework können Gerätehersteller und App-Entwickler thermische Daten verwenden, um für eine konsistente User Experience (UX) zu sorgen, wenn ein Gerät überhitzt. Wenn ein System beispielsweise thermischen Belastungen ausgesetzt ist, werden jobscheduler-Jobs gedrosselt und bei Bedarf wird ein thermisches Herunterfahren des Frameworks eingeleitet. Apps, die Benachrichtigungen zu thermischer Belastung über einen registrierten Callback in der PowerManager-Klasse erhalten, können ihre Benutzeroberfläche entsprechend anpassen.
Thermal HAL
Unter Android 9 und niedriger wird eine Polling-Schnittstelle verwendet, die in Thermal HAL 1.0 definiert ist, um Temperaturmesswerte zu erhalten. Mit diesem HAL konnten das Android-Framework und andere vertrauenswürdige Clients, z. B. das HAL eines Geräteherstellers, die aktuelle Temperatur und die produktspezifischen Drosselungs- und Abschaltgrenzwerte für jeden Sensor über dieselbe API lesen.
Mit Android 10 wurde ein thermisches System im Android-Framework und eine neue Version der HAL, Thermal HAL 2.0, eingeführt, die die Schnittstelle zu den Hardwaregeräten des thermischen Subsystems abstrahiert. Die Hardwareschnittstelle umfasst Temperatursensoren und Thermistoren für Haut, Akku, GPU, CPU und USB-Anschluss. Die Hauttemperatur des Geräts ist das wichtigste System, das überwacht werden muss, um die Oberflächentemperatur des Geräts innerhalb der angegebenen thermischen Grenzwerte zu halten.
Außerdem stellt Thermal HAL 2.0 mehreren Clients Messwerte von Temperatursensoren und die zugehörigen Schweregrade zur Verfügung, um thermische Belastung anzuzeigen. Die folgende Abbildung zeigt zwei Warnmeldungen aus der Benutzeroberfläche des Android-Systems. Diese Meldungen werden angezeigt, wenn die IThermalEventListener-Callback-Schnittstelle für die Sensoren USB_PORT bzw. SKIN den Schweregrad THERMAL_STATUS_EMERGENCY erreicht.
Abbildung 1: Überhitzungswarnungen
Die aktuellen Temperaturen werden für die verschiedenen Typen von thermischen Sensoren über IThermal HAL abgerufen. Jeder Funktionsaufruf gibt einen Statuswert von entweder SUCCESS oder FAILURE zurück. Wenn SUCCESS zurückgegeben wird, wird der Vorgang fortgesetzt. Wenn FAILURE zurückgegeben wird, wird eine für Menschen lesbare Fehlermeldung an status.debugMessage gesendet.
Neben der Abfrageschnittstelle, die die aktuellen Temperaturen zurückgibt, können Sie den Callback IThermalChangedCallback (HIDL, Android 10 bis 13) oder IThermalChangedCallback (AIDL, Android 14 und höher) mit der Callback-Schnittstelle von Thermal HAL-Clients wie dem Thermal-Dienst des Frameworks verwenden. Beispiel: RegisterIThermalChangedCallback und UnregisterIThermalChangedCallback zum Registrieren oder Aufheben der Registrierung von Ereignissen mit geänderter Schwere. Wenn sich die thermische Belastung eines bestimmten Sensors geändert hat, sendet notifyThrottling einen Callback für das Ereignis „Thermal Throttling“ an Listener für thermische Ereignisse.
Zusätzlich zu den Informationen des Wärmesensors wird in getCurrentCoolingDevices eine Liste der Geräte angezeigt, die zur Kühlung beitragen. Die Reihenfolge dieser Liste bleibt bestehen, auch wenn ein Kühlgerät offline gegangen ist. Gerätehersteller können die Liste verwenden, um statsd-Messwerte zu erfassen.
Weitere Informationen finden Sie in der Referenzimplementierung.
Sie können zwar eigene Erweiterungen hinzufügen, sollten die Funktion zur thermischen Belastungsreduzierung jedoch nicht deaktivieren.
Thermischer Service
In Android 10 und höher bietet der Thermalservice im Framework eine konstante Überwachung mithilfe der verschiedenen Minderungssignale aus Thermal HAL 2.0 und gibt Feedback zur Drosselungsstufe an seine Clients. Zu diesen Clients gehören interne Komponenten und Android-Apps. Der Dienst verwendet zwei Binder-Callback-Schnittstellen, IThermalEventListener und IThermalStatusListener, die als Callbacks bereitgestellt werden. Ersteres ist für die interne Verwendung durch Plattform- und Gerätehersteller vorgesehen, letzteres für Android-Apps.
Über die Callback-Schnittstellen kann der aktuelle thermische Status eines Geräts als Ganzzahlwert im Bereich von 0x00000000 (keine Drosselung) bis 0x00000006 (Geräteabschaltung) abgerufen werden. Nur ein vertrauenswürdiger Systemdienst, z. B. eine Android-API oder eine API des Geräteherstellers, kann auf die detaillierten Informationen zu Thermalsensoren und Thermalereignissen zugreifen. Die folgende Abbildung zeigt ein Modell des Ablaufs des Prozesses zur thermischen Entlastung in Android 10 und höher:
Abbildung 2: Ablauf des Prozesses zur thermischen Entlastung in Android 10 und höher.
Richtlinien des Geräteherstellers
Um den Gerätesensor für die Temperatur und den Drosselungsstatus für Android 10 bis 13 zu melden, müssen Gerätehersteller den HIDL-Aspekt von Thermal HAL 2.0 (IThermal.hal) implementieren.
Um den Temperatursensor und den Drosselungsstatus für Android 14 zu melden, müssen Gerätehersteller den AIDL-Aspekt von Thermal HAL 2.0 (IThermal.aidl) implementieren.
Alles, was die Geräteleistung drosselt, einschließlich Einschränkungen der Akkuleistung, muss über das Thermal HAL gemeldet werden. Damit dies geschieht, müssen alle Sensoren, die auf einen Bedarf an Gegenmaßnahmen hinweisen könnten (basierend auf Statusänderungen), in die Thermal HAL aufgenommen und der Schweregrad aller ergriffenen Gegenmaßnahmen gemeldet werden. Der von einer Sensormessung zurückgegebene Temperaturwert muss nicht die tatsächliche Temperatur sein, solange er den entsprechenden Schweregradschwellenwert genau widerspiegelt. Sie können beispielsweise verschiedene numerische Werte anstelle Ihrer tatsächlichen Temperaturschwellenwerte übergeben oder Guardbanding in Schwellenwertspezifikationen einbauen, um eine Hysterese zu ermöglichen. Die Schwere des Problems muss jedoch dem entsprechen, was an diesem Grenzwert erforderlich ist. Sie können beispielsweise 72 °C als kritischen Temperaturgrenzwert zurückgeben, wenn die tatsächliche Temperatur 65 °C beträgt und dem von Ihnen angegebenen kritischen Schweregrad entspricht. Der Schweregrad muss korrekt sein, damit das thermische Framework optimal funktioniert.
Weitere Informationen zu den Schwellenwerten im Framework und dazu, wie sie mit den Maßnahmen zur Risikominderung zusammenhängen, finden Sie unter Thermische Statuscodes verwenden.
Thermische APIs verwenden
Apps können Listener hinzufügen und entfernen und über die Klasse PowerManager auf Informationen zum thermischen Status zugreifen.
Die IThermal-Schnittstelle bietet alle erforderlichen Funktionen, einschließlich der Rückgabe der Werte für den thermischen Status. Die IThermal binder interface wird als OnThermalStatusChangedListener-Schnittstelle umschlossen, die Apps beim Registrieren oder Entfernen von Listenern für den thermischen Status verwenden können.
Die Android Thermal APIs haben sowohl Callback- als auch Polling-Methoden, damit Apps über Statuscodes über die thermischen Schweregrade benachrichtigt werden. Diese sind in der Klasse PowerManager definiert. Die Methoden sind:
getCurrentThermalStatus()gibt den aktuellen thermischen Status des Geräts als Ganzzahl zurück, sofern das Gerät nicht gedrosselt wird.addThermalStatusListener()fügt einen Listener hinzu.- Mit
removeThermalStatusListener()wird ein zuvor hinzugefügter Listener entfernt.
Thermische Statuscodes verwenden
Die thermischen Statuscodes entsprechen bestimmten Drosselungsstufen, die Sie zum Erfassen von Daten und zum Entwerfen einer optimalen Benutzeroberfläche verwenden können. Apps können beispielsweise den Status 0x00000000 (THERMAL_STATUS_NONE) erhalten, der später in 0x00000001 (THERMAL_STATUS_LIGHT) geändert wird. Wenn der Status 0x00000000 als t0 markiert und die Zeit gemessen wird, die vom Status THERMAL_STATUS_NONE bis zum Status THERMAL_STATUS_LIGHT vergeht (t1), können Gerätehersteller für bestimmte Anwendungsfälle Abhilfestrategien entwickeln und testen. In der folgenden Tabelle sind Vorschläge für die Verwendung der Thermostatuscodes aufgeführt:
| Statuscode für Temperatur | Beschreibung und empfohlene Verwendung |
|---|---|
THERMAL_STATUS_NONE (0x00000000) |
Keine Drosselung. Verwenden Sie diesen Status, um Schutzmaßnahmen zu implementieren, z. B. um den Beginn des Zeitraums (t0 bis t1) von THERMAL_STATUS_NONE (0) bis THERMAL_STATUS_LIGHT (1) zu erkennen. |
THERMAL_STATUS_LIGHT (0x00000001) |
Die Helligkeit wird gedrosselt, die Nutzerfreundlichkeit ist nicht beeinträchtigt. Verwenden Sie für diese Phase eine sanfte Geräte-Minderung. Beispiel: Das Steigern oder Verwenden ineffizienter Frequenzen wird übersprungen, aber nur auf großen Kernen. |
THERMAL_STATUS_MODERATE (0x00000002) |
Moderate Drosselung, die Nutzerfreundlichkeit wird nicht stark beeinträchtigt. Die thermische Drosselung wirkt sich auf Vordergrundaktivitäten aus. Apps sollten daher sofort den Stromverbrauch reduzieren. |
THERMAL_STATUS_SEVERE (0x00000003) |
Starke Drosselung; die Nutzerfreundlichkeit ist stark beeinträchtigt. In dieser Phase sollte die thermische Dämpfung des Geräts die Systemkapazität begrenzen. Dieser Zustand kann zu Nebenwirkungen wie Ruckeln des Displays und Audio-Jitter führen. |
THERMAL_STATUS_CRITICAL (0x00000004) |
Die Plattform hat alles getan, um den Stromverbrauch zu senken. Die Software zur thermischen Belastungsreduzierung des Geräts hat alle Komponenten so eingestellt, dass sie mit der niedrigsten Kapazität laufen. |
THERMAL_STATUS_EMERGENCY (0x00000005) |
Wichtige Komponenten der Plattform werden aufgrund der thermischen Bedingungen heruntergefahren und die Gerätefunktionen sind eingeschränkt. Dieser Statuscode steht für die letzte Warnung vor dem Herunterfahren des Geräts. In diesem Zustand sind einige Funktionen wie das Modem und die mobile Datennutzung vollständig deaktiviert. |
THERMAL_STATUS_SHUTDOWN (0x00000006) |
Fahre das Gerät sofort herunter. Aufgrund der Schwere dieser Phase können Apps diese Benachrichtigung möglicherweise nicht empfangen. |
Gerätehersteller müssen den VTS-Test für das Thermal HAL bestehen. Sie können emul_temp über die Kernel-Sysfs-Schnittstelle verwenden, um Temperaturänderungen zu simulieren.