透過 Android 架構，裝置製造商和應用程式開發人員可以使用熱力資料，在裝置開始過熱時確保一致的使用者體驗 (UX)。舉例來說，當系統受到熱力壓力時，jobscheduler 工作就會受到限流，並在必要時啟動架構溫度關閉機制。透過 PowerManager 類別 註冊的回呼接收熱力負載通知的應用程式，可以順利調整使用者體驗。
熱感應 HAL
Android 9 以下版本會使用熱力 HAL 1.0 中定義的輪詢介面取得溫度讀數。這個 HAL 可讓 Android 架構和其他可信任的用戶端 (例如裝置製造商的 HAL) 透過相同的 API，讀取每個感應器的目前溫度，以及產品政策專屬的節流和關閉門檻。
Android 10 在 Android 架構中推出了溫度控制系統，以及新版 HAL (Thermal HAL 2.0)，可將介面抽象化為溫度控制子系統的硬體裝置。硬體介麵包含皮膚、電池、GPU、CPU 和 USB 連接埠的溫度感應器和溫度感應器，為了讓裝置表面溫度維持在指定的熱力限制範圍內，裝置皮膚溫度是最重要的追蹤系統。
此外，Thermal HAL 2.0 會為多個用戶端提供熱感應器讀數和相關嚴重程度，用來表示熱應力。下圖顯示 Android 系統 UI 中的兩則警告訊息。當 USB_PORT 和 SKIN 感應器的 IThermalEventListener 回呼介面分別達到 THERMAL_STATUS_EMERGENCY 嚴重程度時，系統就會顯示這些訊息。
圖 1. 過熱警報。
系統透過 IT 熱 HAL 擷取不同熱力感應器類型目前的溫度。每個函式呼叫都會傳回 SUCCESS 或 FAILURE 的狀態值。如果傳回 SUCCESS，則程序會繼續進行。如果傳回 FAILURE，系統會將錯誤訊息傳送至 status.debugMessage，且該訊息必須是人類可讀的內容。
除了用於擷取目前溫度的輪詢介面，您還可以使用回呼 IThermalChangedCallback (HIDL，Android 10 至 13) 或 IThermalChangedCallback (AIDL，Android 14 以上版本)，搭配熱力 HAL 用戶端的回呼介面 (例如架構的熱力服務)。例如 RegisterIThermalChangedCallback 和 UnregisterIThermalChangedCallback，用於註冊或取消註冊嚴重性變更事件。如果特定感應器的熱嚴重程度已變更，notifyThrottling 會將熱節流事件回呼傳送至熱事件監聽器。
除了熱感應器資訊外，getCurrentCoolingDevices 也會公開一長串已緩解的冷卻裝置。即使冷卻裝置已離線，這個清單的順序仍會維持不變。裝置製造商可以使用這份清單收集 statsd 指標。
詳情請參閱參照實作。
雖然您可以新增自己的擴充功能，但不應停用熱力緩解功能。
熱能服務
在 Android 10 以上版本中，架構中的熱管理服務會使用 Thermal HAL 2.0 提供的各種緩解信號，提供持續監控功能，並向其用戶端提供節流嚴重程度的意見回饋。這些用戶端包含內部元件和 Android 應用程式。服務會使用兩個繫結器回呼介面 (IThermalEventListener 和 IThermalStatusListener)，並將其公開為回呼。前者適用於內部平台和裝置製造商使用，後者適用於 Android 應用程式。
透過回呼介面，裝置目前的熱力狀態可擷取為介於 0x00000000 (無節流) 到 0x00000006 (裝置關閉) 之間的整數值。只有受信任的系統服務 (例如 Android API 或裝置製造商 API) 才能存取詳細的熱感應器和熱事件資訊。下圖為 Android 10 以上版本的溫度緩解程序流程模型：
圖 2. Android 10 以上版本的溫度緩解程序流程。
裝置製造商指南
如要針對 Android 10 至 13 回報裝置溫度感應器和節流狀態，裝置製造商必須實作 Thermal HAL 2.0 (IThermal.hal) 的 HIDL 層面。
如要回報 Android 14 的裝置溫度感應器和節流狀態，裝置製造商必須實作 Thermal HAL 2.0 (IThermal.aidl) 的 AIDL 層面。
任何會降低裝置效能的因素 (包括電池電力限制)，都必須透過熱力 HAL 回報。為確保確實發生這種情況，請將可能指示緩解 (根據狀態變更) 的所有感應器放入熱 HAL，然後回報任何已採取的緩解動作的嚴重程度。只要感應器讀數傳回的溫度值準確反映相應的嚴重程度門檻，就無須是實際溫度。例如，您可以傳遞不同的數值，而非實際的溫度閾值，或者也可以將保護措施限制在閾值規格下以提供支援。不過，對應該值的嚴重性必須符合該門檻所需的嚴重性。舉例來說，您可以將 72°C 設為臨界溫度門檻，當實際溫度為 65°C 時，系統會傳回該值，並對應您指定的臨界嚴重性。為確保熱力管理架構發揮最佳效能，嚴重程度等級必須正確。
如要進一步瞭解架構中的門檻層級，以及這些等級對應於緩解動作的方式，請參閱「使用熱力狀態碼」一文。
使用熱力 API
應用程式可以新增及移除監聽器，並透過 PowerManager 類別存取熱能狀態資訊。IThermal 介面提供所有必要功能，包括傳回熱力狀態值。IThermal 繫結器介面會包裝為 OnThermalStatusChangedListener 介面，應用程式可在註冊或移除熱力狀態監聽器時使用。
Android 熱力 API 提供回呼和輪詢方法，可透過在 PowerManager 類別中定義的狀態碼，通知應用程式熱力嚴重程度。包括：
- 除非裝置正在進行節流，否則
getCurrentThermalStatus()會以整數形式傳回裝置的目前熱力狀態。 addThermalStatusListener()會新增監聽器。removeThermalStatusListener()會移除先前新增的監聽器。
使用熱力狀態碼
熱力狀態碼會轉譯為特定節流層級，您可以用來收集資料，並設計最佳的使用者體驗。舉例來說，應用程式可能會收到 0x00000000 (THERMAL_STATUS_NONE) 狀態，後續可能會變更為 0x00000001 (THERMAL_STATUS_LIGHT)。將 0x00000000 狀態標示為 t0，然後測量從狀態 THERMAL_STATUS_NONE 變更為狀態 THERMAL_STATUS_LIGHT 所需的時間 (t1)，裝置製造商就能針對特定用途設計及測試因應策略。下表列出建議的溫度狀態碼使用方式：
| 過熱狀態碼 | 說明和建議用途 |
|---|---|
THERMAL_STATUS_NONE (0x00000000) |
無須節流。使用這項狀態實作保護動作，例如偵測從 THERMAL_STATUS_NONE (0) 到 THERMAL_STATUS_LIGHT (1) 的時間範圍起始時間 (t0 到 t1)。 |
THERMAL_STATUS_LIGHT (0x00000001) |
輕度調節，使用者體驗則不受影響。在這個階段，請使用溫和的裝置緩解措施。例如，跳過提升或使用效率不佳的頻率，但只在大型核心上執行。 |
THERMAL_STATUS_MODERATE (0x00000002) |
中度調節，使用者體驗並未受到大幅影響。熱管理措施會影響前景活動，因此應用程式應立即降低耗電量。 |
THERMAL_STATUS_SEVERE (0x00000003) |
嚴重過熱保護，使用者體驗受到極大影響。在這個階段，裝置熱管理功能應會限制系統容量。這可能會造成連帶效果，例如顯示卡頓和音訊抖動。 |
THERMAL_STATUS_CRITICAL (0x00000004) |
平台已盡力降低耗電量。裝置熱管理軟體已將所有元件設為以最低容量運作。 |
THERMAL_STATUS_EMERGENCY (0x00000005) |
平台中的關鍵元件會因熱力條件而關閉，導致裝置功能受限。這個狀態碼代表裝置關閉前的最後一次警告。在這個狀態下，部分功能 (例如數據機和行動數據) 會完全關閉。 |
THERMAL_STATUS_SHUTDOWN (0x00000006) |
立即關機。由於此階段嚴重性，應用程式可能無法收到這則通知。 |
裝置製造商必須通過熱 HAL 的 VTS 測試，且可以使用核心 sysfs 介面中的 emul_temp 模擬溫度變化。