adb shell のコマンドはどう実行しますか？

端末で開発者向けオプションと USB デバッグを有効にし、ケーブルを繋いだうえで、platform-tools を入れた機械から adb shell を実行します。adb shell だけを実行すれば対話プロンプトが出て、接頭辞なしで打てます。スクリーンショットのようにバイナリを出力するコマンドでは adb shell ではなく adb exec-out を使ってください。素のシェルサービスは端末を割り当て、それが改行のバイトを書き換えてデータを壊します。

adb shell のコマンドに root は必要ですか？

このリファレンスにあるものには不要です。すべて shell ユーザーとして動き、自分の Android ユーザー向けのパッケージ管理、ほとんどの dumpsys サービスの読み取り、設定プロバイダへの書き込み、入力の注入、共有ストレージの読み取りができます。root が必要なのはこのリファレンスがあえて避けていること、つまり他のアプリのプライベートデータの読み取り（debuggable なビルドに対する run-as を除く）、システムパーティションへの書き込み、/data/anr の直接読み取りです。

自分の端末では出力が違って見えるのはなぜ？

Android のバージョンか、メーカーのどちらかです。一部のフラグやフィールドは特定のリリースから入ったもので、それはコマンドごとに注記しています。残りはメーカーによる改変で、いちばん影響が大きいのは dumpsys です。ダンプはデバッグ出力で、そのテキストはサービスの作者が最後に印字した内容そのもの、しかもメーカーはそれを変えて自分の変更をバックポートします。フィールドは位置ではなく名前で読み、見慣れない形は失敗ではなく差分として扱ってください。

端末ではなくブラウザから実行できますか？

多くのコマンドは可能です。このサイトの Web ADB ツール群は、Chromium 系のデスクトップブラウザから WebUSB で端末と話し、SDK のインストールも不要、どこにもアップロードしません。各ページは、該当するツールがあればそこへリンクしています。知っておく価値のある制限が 2 つあります。ADB インターフェイスを保持できるプログラムは同時に 1 つだけなので、デスクトップの adb server は先に止める必要があります。そして adb forward と adb reverse はブラウザでは一切動きません。

dumpsys thermalservice

読み取りのみ

端末が発熱で性能を絞っているか、そしてハードウェア層が報告する各温度ゾーンを摂氏で表示します。

コマンド: adb shell dumpsys thermalservice
コマンド: システムサービス（dumpsys）
リスク: 読み取りのみ

構文

dumpsys thermalservice

使用例

```
dumpsys thermalservice
```
絞り込みの度合いと、各ゾーンの温度。
```
cat /sys/class/thermal/thermal_zone0/temp
```
カーネル自身の読み。単位は 1000 分の 1 度です。

出力の読み方

出力例

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 です。その下の 2 つの節は同じゾーンを 2 度描いています。ハードウェアの実測とサービスのキャッシュなので、両方並べるのではなく `mName` で統合してください。そうしないと同じゾーンが少し違う温度で 2 回現れます。温度の `mValue` はすでに摂氏の浮動小数点で、割る必要はありません。

出力フィールド

フィールド	意味
Thermal Status	0 NONE、1 LIGHT、2 MODERATE、3 SEVERE、4 CRITICAL、5 EMERGENCY、6 SHUTDOWN。
IsStatusOverride	true なら status は検証用に注入された値で、実測ではありません。
mValue (Temperature)	浮動小数点の摂氏。`NaN` は仕様上の「値なし」を表す印です。
mName	ベンダー独自のゾーン名。標準化されていないので、端末のデータシートと突き合わせてください。
mStatus	そのゾーン自身の絞り込みの度合い。同じ 0〜6 の尺度です。
mValue (CoolingDevice)	ドライバが決めた状態値。cpufreq の段、ファンの番号、デューティ比など。単位はありません。

必要な権限

読み取りのほうは簡単です。`dumpInternal` は `DumpUtils.checkDumpPermission` で守られているだけなので、必要なのは `android.permission.DUMP` ひとつで、Shell パッケージのマニフェストがそれを宣言しています。root も `adb root` も、USB デバッグより先の開発者向けオプションも不要です。書き込みのほうは守り方が違い、このページのどれよりも厳しいです。`ThermalManagerService.onShellCommand` は、呼び出し元の uid が `SHELL_UID` か `ROOT_UID` でなければ即座に拒否し――権限はまったく参照しません――そのうえでシェルコマンドを実行します。そこへ行くのは `cmd thermalservice` であって `dumpsys` ではありません。サービスの `dump` は引数を `dumpInternal` に渡し、`dumpInternal` はそれを完全に無視するので、`cmd thermalservice override-status <n>` が `IsStatusOverride: true` にする一方、`dumpsys thermalservice override-status <n>` は黙ってダンプを表示するだけで何も変えません。override されたまま放置された端末は、どのセンサーも出していない絞り込みの度合いを無期限に報告し続け、このダンプを読むすべてのツールがそれを信じます。戻る道は `cmd thermalservice reset` です。`Thermal Status` を信じる前に `IsStatusOverride` を、必ずその順で、毎回読んでください。自分が触っていない端末でもです。override はそれを設定したシェルセッションより長く生き残るので、前に触った人が消していないかもしれません。Android Sensor Tester が送るのは読み取りの形だけです。

エラーメッセージの読み解き

メッセージ	意味
Permission Denial: can't dump ThermalManagerService from from pid=4821, uid=10231 due to missing android.permission.DUMP permission	`DumpUtils.checkDumpPermission` が出す行で、タグはサービス自身のクラス名から取られ、AOSP のダンプ拒否につきものの `from from` の重複も付いています。標準出力に、ダンプ全体の代わりに書かれます。だから手元にあるのは温度ゾーンの無い端末ではなく、サービスに届かなかった呼び出しです。
* SERVICE 'thermalservice' DUMP TIMEOUT (10000ms) EXPIRED *	`dumpsys` バイナリが既定の 10 秒で待つのをやめました。このダンプはハードウェア層から全ゾーンを読むあいだサービス全体のロックを握るので、固まった thermal HAL は HAL 自身のエラーではなくここに現れます。バナーより前に印字されたものは本物です。切れたゾーン一覧を全体だと思い込まず、結論を出す前に `-t SECONDS` で待ち時間を伸ばしてください。
Can't find service: thermalservice	サービスマネージャに `thermalservice` の登録が無いときに `dumpsys` バイナリが標準エラーへ出す行で、起動途中なら普通のことです。標準エラーに出るので、`2>&1` なしで拾った実行では、理由がどこにも書かれていない空のダンプだけが残ります。
cmd: Can't find service: thermalservice	同じ不在を別の道具から見たものです。`cmd:` という接頭辞が、これは `cmd` から来たと教えてくれます。つまり失敗したのは読み取りではなく override か reset の側で、消したつもりの override がまだ残っているということです。サービスが上がったら `IsStatusOverride` で確認してください。

バージョンとメーカーに関する注意

ここで温度の尺度が 3 つ交差します。このダンプは浮動小数点の摂氏、`dumpsys battery` は 10 分の 1 度、`/sys/class/thermal/*/temp` は 1000 分の 1 度です。片方の換算を他方の数値に当てると、もっともらしい 10 倍の誤りになります。
Android が定義していない severity の値は、いちばん不穏な SHUTDOWN に丸めるのではなく不明として見せるべきです。
ゾーン名も、対象範囲も、そもそもハードウェア層が答えるかどうかもメーカー次第です。
`dumpsys thermalservice reset` は何もリセットしません。サービスの `dump` は引数を `dumpInternal` に渡し、`dumpInternal` はそれを無視してダンプを出し直すだけです。override を設定するのは `cmd thermalservice override-status <n>`、消すのは `cmd thermalservice reset` で、引数の扱いは `dumpsys battery` とちょうど逆です。
`… from HAL:` の節は `HAL Ready: true` のあいだしか印字されません。そのうち static thresholds の節は他の 2 つより新しく、tag android-11.0.0_r1 には無く android-12.0.0_r1 から現れます。

これには UI があります

Android Sensor Tester はこのコマンドを USB 経由で実行し、返ってきたものを解析します。Chromium 系ブラウザだけで、SDK も不要、どこにもアップロードしません。

Android Sensor Tester を開く

コマンド	何をするか
dumpsys battery	バッテリーサービスの現在の状態：残量、充電状態、健康度、電圧、温度。
top	1 回分のプロセス表：CPU 使用率、メモリ、状態、コマンドライン。
dumpsys meminfo	どのプロセスがメモリを最も使っているかを、PSS（比例配分したサイズ）で表示します。

他のシステムサービス（dumpsys）コマンド

コマンド	何をするか
dumpsys diskstats	パーティションごとの空き容量、ディスク書き込み遅延の実測、そしてキャッシュされたアプリ別の使用量内訳。
dumpsys sensorservice	端末にあるすべてのセンサーとそのベンダー、type、レート、バッチング。加えて直近の測定値のバッファ。
dumpsys package	パッケージマネージャが知っているすべて：バージョン、パス、flags、インストール元、ユーザーごとの状態。
dumpsys activity activities	いまどのアプリが前面にいるか、そしてその背後のタスクとスタックの構造。
dumpsys dropbox	クラッシュ、ANR、tombstone を保持するプラットフォームのリングバッファ。root なしで ANR トレースを読む方法です。

Web ADB ツール群のパーサを書きながら、AOSP・toybox・カーネルのソースに突き合わせて確認しています。バージョンやメーカーで本当に挙動が変わるところは、世界の半分の端末で間違いになる数値を出す代わりに、そう書いてあります。