借助 Android 框架，設備製造商和應用程式開發人員可以使用熱數據在設備開始過熱時確保一致的使用者體驗 (UX)。例如，當系統遭受熱應力時， jobscheduler作業會受到限制，如有必要，也會啟動框架熱關閉。透過PowerManager類別中註冊的回調接收熱應力通知的應用程式可以優雅地調整其 UX。
熱哈爾
Android 9 及更低版本使用 Thermal 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.過熱警告。
透過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 中，並報告所採取的任何緩解措施的嚴重性。從感測器讀數返回的溫度值不必是實際溫度，只要它準確反映相應的嚴重性閾值即可。例如，您可以傳遞不同的數值而不是實際溫度閾值，或者可以將保護帶建置到閾值規格中以提供滯後。但是，與該值對應的嚴重性必須與該閾值所需的嚴重性相符。例如，您可能決定返回 72°C 作為臨界溫度閾值，而實際溫度為 65°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 ） | 沒有節流。使用此狀態來實施保護操作，例如偵測從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來模擬溫度變化。