DevCheck 多溫度點面板拆解——為什麼它比系統資訊多讀五個感測器

DevCheck 是什麼——一個把「手機內部情況」全部攤開的工具

DevCheck 是 Android 上一款硬體檢測工具，它把手機裡你平時看不見的那堆資訊——SoC 型號、記憶體頻率、電池健康度、各個溫度感測器、所有已安裝應用的簽名指紋、感測器即時數據——全部攤在一個介面上。它不像系統設定裡那樣只給你幾個籠統的數字，而是往每個模組底下鑽：電池溫度不是一個數字，是電池本體、SoC、充電晶片、面板、Wi-Fi 模組各自的讀值；已安裝應用不是一個清單，是包名、版本號、安裝體積、APK 路徑、首次安裝時間、最後更新時間、簽名證書指紋。

適合誰？大致三種人。一是驗機場景：二手手機交易時，打開 DevCheck 把所有讀值掃一遍，比系統設定可靠得多。二是發燒友：想知道自己的 SoC 超頻、冷卻殼效果如何，要看持續的溫度感測器資料。三是排查疑難雜症：手機發熱、續航變差、某個硬體失靈，先讓 DevCheck 讀一圈，定位問題再動手。

安裝

DevCheck下载 的 APK 約 17.83M，支援 Android 7.0+。安裝路徑和一般第三方應用一樣，但有兩個容易踩的坑值得寫在這裡。第一個是「未知來源」的授權對象：Android 8.0 之後，不是在一個全域開關，而是要給你正在用它下載 APK 的那個應用——用瀏覽器下載就給瀏覽器開，用檔案管理器點開就給那個管理器開。很多人卡住就是因為給錯了對象。第二個是簽名衝突：如果你手機裡已經從應用商店裝過另一個來源的 DevCheck，系統會拒絕安裝這份——先卸下已裝的再裝這份就行，DevCheck 本身不存使用者資料，卸下沒有損失。

裝完打開就是儀表盤首頁。默認情況下，大部分機型只能看到電池溫度一個讀值。如果你點那個溫度數字會發現，界面其實預留了 SoC、充電晶片、面板、Wi-Fi 四個空位，只是讀不出來——這就是下面要拆解的問題。

為什麼系統設定只顯示一個溫度，而 DevCheck 能讀五個——三層機制拆解

你打開系統設定，只能看到一個電池溫度。打開 DevCheck，點一下那個溫度數字，突然跳出 SoC、充電晶片（PMIC）、面板、Wi-Fi 模組四個額外的溫度讀值。這件事看起來像是 DevCheck「額外拿到了權限」，但實際上是三個不同層面的東西疊在一起的結果：Android 的權限模型、硬體廠商的底層回報、Shizuku 的繞路機制。

第一層：Android 本來就把這些感測器鎖起來了

Android 8.0（API 26）之前，任何應用只要調用 SensorManager 的 getSensorList()，就能拿到所有溫度感測器——電池、CPU、GPU、環境溫度，全都在裡面。但 8.0 之後，Google 改了權限模型：普通 normal 權限的應用只能讀到電池溫度，其他溫度感測器的讀值直接返回空數組或 0。這不是 DevCheck 沒本事讀，是 Android 系統硬擋在那裡。

為什麼擋？Google 的說法是「隱私保護」——不讓第三方應用拿到過多硬體細節。但實際上，溫度感測器讀值本身不涉及隱私，真正的原因是 Google 想把「系統資訊的完整讀取」收歸自己管，給 Play 服務和系統應用特權。普通開發者就被卡在這道牆外面。

第二層：哪些機型硬體上真的有這些感測器

就算 Android 不擋，也不是每台手機都有這麼多溫度點。中低端機型通常只有電池和 SoC 兩個溫度感測器，甚至有些連 SoC 的都沒有——SoC 溫度讀值是電池溫度通過演算法推算出來的，不是真的感測器讀值。高端機型會多出充電晶片（PMIC）的溫度感測器，因為快充時候 PMIC 發熱量不可忽視，廠商需要獨立監控。屏幕面板和 Wi-Fi 模組的溫度感測器更稀有，通常只在旗艦機型上才看得到。

DevCheck 在讀不到某個溫度點時，不會顯示假數字，而是直接顯示「感測器不可用」或該項缺失。這和一些把推算值當成真實感測器值顯示的工具不同——DevCheck 的策略是寧可不顯示也不造假。

第三層：Shizuku 怎麼繞過 Android 的限制

這是最有意思的部分。裝了 Shizuku 之後，之前讀不到的 SoC、充電晶片、面板、Wi-Fi 溫度點大概率會自動跑出來。很多人以為 Shizuku 是「root 的替代品」，但實際上 Shizuku 做的事情比 root 精準得多。

Android 系統裡有一批 API，標記為 @SystemApi 或隱藏 API——普通應用看不到也調不了，但系統進程（system_server）本身可以調。Shizuku 的原理是：它通過 ADB 或 root 權限，在 system_server 裡啟動一個服務，然後把系統 API 的調用權限透傳給連接它的應用。DevCheck官網 開發時寫了兩套讀取邏輯：一套是普通應用走的 SensorManager，拿不到就 fallback；另一套是 Shizuku 連接後走的隱藏 API 路徑，直接讀硬體廠商在 /sys/class/thermal/ 下掛載的原始溫度值。

這個區別很重要——DevCheck 不是「拿到了權限」，而是「換了一條本來只有系統才能走的路」。Shizuku 本身不讀溫度，它只負責把這條路打通。DevCheck 在 Shizuku 環境下讀到的是硬體廠商直接回報的原始感測器值，而不是 Android Framework 經過一層處理後的值。

取舍與代價

這套設計有三個代價。第一個是 Shizuku 本身的使用門檻：需要電腦連一次 ADB 啟動，或者 root 機型手動啟動，對普通使用者不友好。第二個是 Shizuku 服務如果被系統殺掉，DevCheck 會瞬間回到只能讀電池溫度的狀態——需要重啟 Shizuku 才能恢復。第三個是部分廠商的隱藏 API 路徑不走 Shizuku 也能讀（比如某些國產 ROM 對自家應用開了後門），但大部分主流機型還是要靠 Shizuku 才能讀全。

什麼場景會失效？如果硬體本身就沒有多溫度感測器（中低端機型），Shizuku 也讀不出來——這時候不是權限問題，是硬體問題。另外，如果手機廠商在 ROM 裡把 /sys/class/thermal/ 的權限改了（越來越多廠商這麼做），Shizuku 的隱藏 API 路徑也會失敗。

這套原理意味著什麼

對 DevCheck 這款工具本身來說，它做對了一件事：把「硬體上真有什麼」和「Android 讓不讓你讀」這兩件事分開處理。普通應用面對 Android 的權限牆要麼認命、要麼 root，DevCheck 選擇了 Shizuku 這個中間層，在不 root 的情況下拿到了系統級的讀取能力。這個思路其實很聰明——很多需要讀硬體細節的工具（磁盤讀寫、定位精度調試）都開始走 Shizuku 這條路。

對使用者來說，裝不裝 Shizuku 決定了 DevCheck 是一個「還不錯的電池監控工具」還是一個「真正完整的硬體檢測儀」。如果你只是偶爾看一眼電池溫度，不裝 Shizuku 也夠用；如果你是發燒友、驗機人員、或者手機出現了發熱問題需要定位，Shizuku 解鎖後的完整感測器面板才是 DevCheck 的核心價值所在。

而這一切的起點，就是你在儀表盤上點了一下那個電池溫度數字。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。