Mit dem Android-Framework können Gerätehersteller und App-Entwickler thermische Daten nutzen, um eine konsistente Benutzererfahrung (UX) sicherzustellen, wenn ein Gerät zu überhitzen beginnt. Wenn beispielsweise ein System einer thermischen Belastung ausgesetzt ist, werden jobscheduler Jobs gedrosselt und bei Bedarf eine thermische Abschaltung des Frameworks eingeleitet. Apps, die über einen registrierten Rückruf in der PowerManager Klasse Benachrichtigungen über thermische Belastung erhalten, können ihre UX elegant anpassen.
Thermisches HAL
Android 9 und niedriger verwenden eine in Thermal HAL 1.0 definierte Abfrageschnittstelle, um Temperaturmesswerte zu erhalten. Dieser HAL ermöglichte es dem Android-Framework und anderen vertrauenswürdigen Clients, z. B. dem HAL eines Geräteherstellers, die aktuelle Temperatur und produktrichtlinienspezifische Drosselungs- und Abschaltschwellenwerte für jeden Sensor über dieselbe API zu lesen.
Mit Android 10 wurde ein thermisches System im Android-Framework und eine neue Version des HAL, Thermal HAL 2.0, eingeführt, die die Schnittstelle zu den Hardwaregeräten des thermischen Subsystems abstrahiert. Die Hardware-Schnittstelle umfasst Temperatursensoren und Thermistoren für Haut, Akku, GPU, CPU und USB-Anschluss. Die Hauttemperatur des Geräts ist das wichtigste zu überwachende System, um die Oberflächentemperatur des Geräts innerhalb bestimmter thermischer Grenzen zu halten.
Darüber hinaus stellt Thermal HAL 2.0 mehreren Clients Temperatursensorwerte und zugehörige Schweregrade zur Verfügung, um thermische Belastung anzuzeigen. Die folgende Abbildung zeigt zwei Warnmeldungen der Android-Systembenutzeroberfläche. Diese Meldungen werden angezeigt, wenn die IThermalEventListener Rückrufschnittstelle für die USB_PORT und SKIN Sensoren jeweils den Schweregrad THERMAL_STATUS_EMERGENCY erreicht.
Abbildung 1. Überhitzungswarnungen.
Die aktuellen Temperaturen werden für die verschiedenen Arten von Wärmesensoren über IThermal HAL abgerufen. Jeder Funktionsaufruf gibt den Statuswert SUCCESS oder FAILURE zurück. Wenn SUCCESS zurückgegeben wird, wird der Prozess fortgesetzt. Wenn FAILURE zurückgegeben wird, wird eine Fehlermeldung, die für Menschen lesbar sein muss, an status.debugMessage gesendet.
Zusätzlich dazu, dass es sich um eine Abfrageschnittstelle handelt, die die aktuellen Temperaturen zurückgibt, können Sie den Rückruf IThermalChangedCallback (HIDL, Android 10 bis 13) oder IThermalChangedCallback (AIDL, Android 14 und höher) mit der Rückrufschnittstelle von thermischen HAL-Clients wie den Frameworks verwenden thermischer Service. Zum Beispiel RegisterIThermalChangedCallback und UnregisterIThermalChangedCallback , um Ereignisse mit geändertem Schweregrad zu registrieren oder die Registrierung aufzuheben. Wenn sich der thermische Schweregrad eines bestimmten Sensors geändert hat, sendet notifyThrottling einen Rückruf für ein thermisches Drosselungsereignis an Thermal-Event-Listener.
Zusätzlich zu den Informationen zu Wärmesensoren wird in getCurrentCoolingDevices eine Liste der entschärften Kühlgeräte angezeigt. Die Reihenfolge dieser Liste bleibt bestehen, auch wenn ein Kühlgerät offline gegangen ist. Gerätehersteller können die Liste verwenden, um statsd zu sammeln.
Weitere Informationen finden Sie in der Referenzimplementierung .
Sie können zwar Ihre eigenen Erweiterungen hinzufügen, sollten die Funktion zur thermischen Abschwächung jedoch nicht deaktivieren.
Wärmeservice
In Android 10 und höher sorgt der Thermal-Dienst im Framework für eine ständige Überwachung mithilfe der verschiedenen Abhilfesignale von Thermal HAL 2.0 und gibt seinen Clients Feedback zum Schweregrad der Drosselung. Zu diesen Clients gehören interne Komponenten und Android-Apps. Der Dienst verwendet zwei Binder-Rückrufschnittstellen, IThermalEventListener und IThermalStatusListener , die als Rückrufe bereitgestellt werden. Ersteres ist für die interne Nutzung von Plattformen und Geräteherstellern bestimmt, Letzteres für Android-Apps.
Über die Rückrufschnittstellen ist der aktuelle thermische Status eines Geräts als ganzzahliger Wert im Bereich von 0x00000000 (keine Drosselung) bis 0x00000006 (Gerät heruntergefahren) abrufbar. Nur ein vertrauenswürdiger Systemdienst, z. B. eine Android-API oder eine Gerätehersteller-API, kann auf die detaillierten Informationen zu Wärmesensoren und thermischen Ereignissen zugreifen. Die folgende Abbildung zeigt ein Modell des Prozessablaufs zur thermischen Abschwächung in Android 10 und höher:
Abbildung 2. Prozessablauf zur Wärmeminderung in Android 10 und höher.
Richtlinien des Geräteherstellers
Um den Gerätetemperatursensor 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 Gerätetemperatursensor 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 Batterieleistung, muss über den thermischen HAL gemeldet werden. Um sicherzustellen, dass dies geschieht, fügen Sie alle Sensoren, die einen Bedarf an Abhilfemaßnahmen (basierend auf Statusänderungen) anzeigen könnten, in den thermischen HAL ein und melden Sie den Schweregrad aller ergriffenen Abhilfemaßnahmen. Der von einem Sensormesswert zurückgegebene Temperaturwert muss nicht die tatsächliche Temperatur sein, solange er den entsprechenden Schwereschwellenwert genau widerspiegelt. Beispielsweise können Sie anstelle Ihrer tatsächlichen Temperaturschwellenwerte andere numerische Werte übergeben oder Sie können Schutzbänder in Schwellenwertspezifikationen integrieren, um eine Hysterese bereitzustellen. Der diesem Wert entsprechende Schweregrad muss jedoch mit den Anforderungen an diesem Schwellenwert übereinstimmen. Beispielsweise könnten Sie entscheiden, 72 °C als kritischen Temperaturschwellenwert zurückzugeben, wenn die tatsächliche Temperatur 65 °C beträgt und dies dem von Ihnen angegebenen kritischen Schweregrad entspricht. Der Schweregrad muss genau sein, um die beste Funktionalität des Wärmegerüsts zu gewährleisten.
Weitere Informationen zu den Schwellenwerten im Framework und wie sie mit Abhilfemaßnahmen korrespondieren, finden Sie unter Verwenden von thermischen Statuscodes .
Verwenden Sie thermische APIs
Apps können über die PowerManager Klasse Listener hinzufügen und entfernen und auf thermische Statusinformationen zugreifen. Die IThermal Schnittstelle bietet alle erforderlichen Funktionen, einschließlich der Rückgabe der thermischen Statuswerte. Die IThermal-Binder-Schnittstelle ist als OnThermalStatusChangedListener Schnittstelle verpackt, die Apps beim Registrieren oder Entfernen von Wärmestatus-Listenern verwenden können.
Die thermischen Android-APIs verfügen sowohl über Rückruf- als auch Abfragemethoden für Apps, um über Statuscodes, die in der PowerManager Klasse definiert sind, über den thermischen Schweregrad informiert zu werden. Die Methoden sind:
-
getCurrentThermalStatus()gibt den aktuellen thermischen Status des Geräts als Ganzzahl zurück, es sei denn, das Gerät unterliegt einer Drosselung. -
addThermalStatusListener()fügt einen Listener hinzu. -
removeThermalStatusListener()entfernt einen zuvor hinzugefügten Listener.
Verwenden Sie thermische Statuscodes
Die thermischen Statuscodes werden in bestimmte Drosselungsstufen übersetzt, die Sie zum Sammeln von Daten und zum Entwerfen einer optimalen UX verwenden können. Beispielsweise erhalten Apps möglicherweise den Status 0x00000000 ( THERMAL_STATUS_NONE ), der sich später möglicherweise in 0x00000001 ( THERMAL_STATUS_LIGHT ) ändert. Das Markieren des 0x00000000 -Status als t0 und das anschließende Messen der Zeit, die vom Status THERMAL_STATUS_NONE bis zum Status THERMAL_STATUS_LIGHT als t1 verstrichen ist, ermöglicht es Geräteherstellern, Abhilfestrategien für bestimmte Anwendungsfälle zu entwerfen und zu testen. In der folgenden Tabelle werden empfohlene Möglichkeiten zur Verwendung der thermischen Statuscodes aufgeführt:
| Thermischer Statuscode | Beschreibung und empfohlene Verwendung |
|---|---|
THERMAL_STATUS_NONE ( 0x00000000 ) | Keine Drosselung. Verwenden Sie diesen Status, um Schutzmaßnahmen zu implementieren, z. B. die Erkennung des Beginns des Zeitraums (t0 bis t1) von THERMAL_STATUS_NONE ( 0 ) bis THERMAL_STATUS_LIGHT ( 1 ). |
THERMAL_STATUS_LIGHT ( 0x00000001 ) | Leichte Drosselung, UX ist nicht beeinträchtigt. Verwenden Sie in dieser Phase eine sanfte Geräteminderung. Überspringen Sie beispielsweise das Boosten oder die Verwendung ineffizienter Frequenzen, jedoch nur bei großen Kernen. |
THERMAL_STATUS_MODERATE ( 0x00000002 ) | Moderate Drosselung, UX wird nicht stark beeinträchtigt. Die thermische Abschwächung wirkt sich auf Aktivitäten im Vordergrund aus, daher sollten Apps den Stromverbrauch sofort reduzieren. |
THERMAL_STATUS_SEVERE ( 0x00000003 ) | Starke Drosselung; UX ist weitgehend betroffen. In dieser Phase sollte die thermische Abschwächung des Geräts die Systemkapazität begrenzen. Dieser Zustand kann Nebenwirkungen wie Anzeigestörungen und Audio-Jitter verursachen. |
THERMAL_STATUS_CRITICAL ( 0x00000004 ) | Die Plattform hat alles getan, um die Leistung zu reduzieren. Die Software zur thermischen Abschwächung 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 thermischer Bedingungen abgeschaltet und die Gerätefunktionalität ist eingeschränkt. Dieser Statuscode stellt die letzte Warnung vor dem Herunterfahren des Geräts dar. In diesem Zustand sind einige Funktionen, z. B. Modem und Mobilfunkdaten, vollständig deaktiviert. |
THERMAL_STATUS_SHUTDOWN ( 0x00000006 ) | Sofort abschalten. Aufgrund der Schwere dieser Phase können Apps diese Benachrichtigung möglicherweise nicht empfangen. |
Gerätehersteller müssen den VTS-Test für thermisches HAL bestehen und können emul_temp über die sysfs-Schnittstelle des Kernels verwenden, um Temperaturänderungen zu simulieren.