dumpsys thermalservice

語法

dumpsys thermalservice

範例

• dumpsys thermalservice

  節流等級加上每個溫區的溫度。

• cat /sys/class/thermal/thermal_zone0/temp

  核心自己的讀數，單位是千分之一度。

輸出怎麼讀

IsStatusOverride: false
Thermal Status: 0
Cached temperatures:
  Temperature{mValue=32.5, mType=2, mName=battery, mStatus=0}
HAL Ready: true
Current temperatures from HAL:
  Temperature{mValue=32.5, mType=2, mName=battery, mStatus=0}
Current cooling devices from HAL:
  CoolingDevice{mValue=0, mType=2, mName=thermal-cpufreq-0}

`Thermal Status` 是整台裝置的節流等級，0 到 6。它底下有兩個段落在描述同一組溫區——硬體的即時讀數與服務的快取副本——所以要用 `mName` 把它們合併，而不是兩份都列出來，否則同一個溫區會以略微不同的溫度出現兩次。溫度的 `mValue` 已經是浮點數的攝氏，不需要再除。

輸出欄位

需要什麼權限

讀取是簡單的那一半：`dumpInternal` 由 `DumpUtils.checkDumpPermission` 守著，所以只要 `android.permission.DUMP`，而 Shell 套件的資訊清單有宣告。不用 root、不用 `adb root`，除了 USB 偵錯之外也沒有開發人員選項要開。寫入的守法不一樣，而且比這一頁上任何東西都嚴。`ThermalManagerService.onShellCommand` 除非呼叫方的 uid 是 `SHELL_UID` 或 `ROOT_UID`，否則直接拒絕——它根本不看權限——通過了才執行它的 shell 指令。而那條路是 `cmd thermalservice` 走的，不是 `dumpsys`：這個服務的 `dump` 把參數交給 `dumpInternal`，而後者完全忽略它們，所以 `cmd thermalservice override-status <n>` 會讓 `IsStatusOverride: true`，而 `dumpsys thermalservice override-status <n>` 只會安靜地印出 dump、什麼都不改。一台被留在覆寫狀態的手機會無限期回報一個沒有任何感測器產生過的節流等級，而每一個讀這份輸出的工具都會信它；`cmd thermalservice reset` 是回頭的路。每一次都要先讀 `IsStatusOverride` 再去信 `Thermal Status`，順序就是這樣——包括在一台你沒碰過的手機上，因為覆寫活得比設定它的那次 shell 連線更久，而前一個人可能沒有清掉。Android Sensor Tester 只會送出讀取的那個形式。

失敗訊息對照

版本與廠商注意事項

• 三種溫度刻度在這裡交會：這份輸出印浮點數的攝氏、`dumpsys battery` 印十分之一度、`/sys/class/thermal/*/temp` 印千分之一度。把其中一種的換算套到另一種的數值上，會得到一個看起來很合理的十倍錯誤。
• Android 沒有定義的等級數值應該顯示為未知，而不是向上取整成最駭人的 SHUTDOWN。
• 溫區名稱、涵蓋範圍，甚至硬體層會不會回應，都因廠牌而異。
• `dumpsys thermalservice reset` 什麼都不會重設。這個服務的 `dump` 把參數交給 `dumpInternal`，後者忽略它們並再印一次 dump；覆寫是用 `cmd thermalservice override-status <n>` 設的，用 `cmd thermalservice reset` 清掉——和 `dumpsys battery` 對待參數的方式正好相反。
• `… from HAL:` 那幾段只有在 `HAL Ready: true` 的時候才會印，而其中 static thresholds 那一段比另外兩段新：tag android-11.0.0_r1 沒有，從 android-12.0.0_r1 起才有。

相關指令

和 dumpsys thermalservice 會在同一次作業裡出現的指令。

其他系統服務（dumpsys）指令