裝置製造商和應用程式開發人員可透過 Android 架構使用溫度資料，確保裝置開始過熱時，使用者體驗 (UX) 不會受到影響。舉例來說，當系統承受熱壓力時，jobscheduler 工作會受到節流，必要時，系統會啟動架構熱關機。應用程式透過 PowerManager 類別中註冊的回呼接收熱壓力通知後，可以適當調整使用者體驗。
熱能 HAL
Android 9 以下版本會使用 Thermal HAL 1.0 中定義的輪詢介面，取得溫度讀數。Android 架構和其他受信任的用戶端 (例如裝置製造商的 HAL) 可透過這個 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. 過熱警告。
系統會透過 IThermal 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，並回報所採取任何緩解措施的嚴重程度。感應器讀取值傳回的溫度值不一定要是實際溫度，只要能準確反映相應的嚴重程度門檻即可。舉例來說，您可以傳遞不同的數值，而非實際的溫度門檻值，也可以在門檻規格中加入保護帶，提供遲滯效應。不過，該值對應的嚴重程度必須符合該門檻的需求。舉例來說，假設實際溫度為 65°C，且對應您指定的嚴重程度，您可能會決定將 72°C 設為臨界溫度門檻。嚴重程度必須準確，才能發揮最佳的熱架構功能。
如要進一步瞭解架構中的閾值等級，以及這些等級對應的緩解措施，請參閱「使用熱狀態代碼」。
使用熱感應 API
應用程式可以新增及移除監聽器，並透過 PowerManager 類別存取溫度狀態資訊。IThermal 介面提供所有必要功能，包括傳回溫度狀態值。IThermal binder 介面會包裝為 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) |
不節流。您可以使用這個狀態實作保護措施，例如偵測時間範圍 (t0 到 t1) 的開始時間，從 THERMAL_STATUS_NONE (0) 到 THERMAL_STATUS_LIGHT (1)。 |
THERMAL_STATUS_LIGHT (0x00000001) |
輕微過熱保護，使用者體驗不受影響。請在這個階段使用溫和的裝置緩解措施。舉例來說，略過提升或使用效率不彰的頻率，但僅限於大型核心。 |
THERMAL_STATUS_MODERATE (0x00000002) |
過熱保護程度中等，使用者體驗不會受到太大影響。熱能減緩措施會影響前景活動，因此應用程式應立即減少耗電量。 |
THERMAL_STATUS_SEVERE (0x00000003) |
嚴重過熱保護，使用者體驗受到大幅影響。在這個階段，裝置的熱能調控機制應會限制系統容量。這種狀態可能會導致連帶效應，例如顯示畫面抖動和音訊抖動。 |
THERMAL_STATUS_CRITICAL (0x00000004) |
平台已盡一切努力減少耗電量。裝置的熱能調控軟體已將所有元件的運作量降至最低。 |
THERMAL_STATUS_EMERGENCY (0x00000005) |
由於熱力狀況，平台中的重要元件正在關閉，裝置功能受到限制。這個狀態碼代表裝置關機前的最後警告。在此狀態下，數據機和行動數據等部分功能會完全關閉。 |
THERMAL_STATUS_SHUTDOWN (0x00000006) |
立即關機。由於這個階段的嚴重程度，應用程式可能無法收到這項通知。 |
裝置製造商必須通過 Thermal HAL 的 VTS 測試，並可使用emul_temp從核心 sysfs 介面模擬溫度變化。