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 meminfo

読み取りのみ

どのプロセスがメモリを最も使っているかを、PSS（比例配分したサイズ）で表示します。

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

構文

dumpsys meminfo

使用例

```
dumpsys meminfo
```
要約の節：プロセス別のメモリと RAM 全体の合計。
```
top -b -n 1 -m 10
```
こちらの方が安く、比例配分ではなく実メモリが得られます。

出力の読み方

出力例

Applications Memory Usage (in Kilobytes):
Uptime: 5178721 Realtime: 5178721

Total PSS by process:
    353,876K: com.google.android.gms.persistent (pid 3062 / activities)
    215,668K: system (pid 1650)
     94,952K: surfaceflinger (pid 842)

行は既に大きい順で、数値はカンマ区切りのキロバイトです。`1,234,567K` は 1 つの数値で、最初のカンマで止める読み方をすると 1.2 GB のプロセスを 1 MB と報告します。PSS は共有ページをそれを写しているプロセスの数で割るので、合計しても実際の使用量に近い値になります。RSS ではそうなりません。

出力フィールド

フィールド	意味
N,NNNK:	キロバイト単位の PSS。カンマ区切り。
(pid N / activities)	プロセス id と修飾語（`activities`、`services`、`cached`）。同じメモリを抱えた生きたアプリとキャッシュ済みの残骸を見分ける手がかりです。
Total RAM / Free RAM / Used RAM	端末全体の合計。こちらもカンマ区切りのキロバイト。

必要な権限

権限は 2 つ、どちらも既に持っています。メモリの binder は `DumpUtils.checkDumpAndUsageStatsPermission` を `meminfo` という小文字のタグそのままで呼ぶので、拒否の行にはクラス名ではなくこの単語が出ます。求められるのは `android.permission.DUMP` と `android.permission.PACKAGE_USAGE_STATS` の両方です。Shell のマニフェストは両方を宣言していて、usage-stats の経路は app-op を見る前に `SHELL_UID` を短絡するため、認可済みの `adb` 接続で足ります。root も `adb root` も、設定の「使用状況へのアクセス」も不要です。計画に織り込むべきなのは権限ではなくコストで、しかもプロセスを 1 つずつ歩くという説明から想像するより悪いです。binder の `dump` はダンプ全体を `enableFreezer(false)` … `enableFreezer(true)` で挟むので、このコマンドが走っているあいだ **端末上の凍結されたキャッシュ済みアプリはすべて解凍され**、終わってから再び凍結されます。そのうえで生き残った各プロセスに binder トランザクションが飛び、各プロセスが自分のメモリマップを歩いて自分の数字を計算します。つまりこれをタイマーで回すのは端末を測るのではなく、測っている対象そのものを変えることです。何のコストも掛かっていなかったキャッシュ済みアプリが目を覚まし、調べていたはずの CPU の山に自分の道具の分が混ざります。Android System Monitor がこれをトグルの裏でゆっくりした間隔でしか送らないのはこのためで、実メモリで足りるなら `top` が安上がりな答えです。

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

メッセージ	意味
Permission Denial: can't dump meminfo from from pid=4821, uid=10231 due to missing android.permission.DUMP permission	タグが `meminfo` という素の単語なのは、メモリの binder がその文字列をそのまま渡しているからです。`from from` の重複も本物の AOSP のテキストです。標準出力に、表の代わりに書かれるので、`K:` の行を探す自動処理は、拒否された呼び出しではなく「プロセスの無い端末」を見ることになります。
* SERVICE 'meminfo' DUMP TIMEOUT (10000ms) EXPIRED *	10 秒は `dumpsys` の既定値で、この一族で最も到達しやすいのがこのダンプです。締め切りが各プロセス自身のマップ走査まで含むからです。手元に残るのは切れた表で、行は大きい順なので欠けるのは小さいプロセスです。したがって切れたダンプでも「いちばん大きいのは何か」には答えられますが、端末全体の合計として足し上げることは決してできません。
Unknown argument: -x; use -h for help	メモリのダンプの引数ループが知らないオプションです。これを標準出力に出したうえで、中断せずに理解できた引数だけで続行します。打ち間違えたフラグは、エラーではなく形の違うダンプ一式になって返ってくるわけです。ここでの失敗の仕方は、尋ねていない問いへのもっともらしい答えです。
Can't find service: meminfo	`dumpsys` バイナリが標準エラーへ出す行で、サービスマネージャに `meminfo` の登録がありません。起動完了前や `system_server` の再起動後には普通のことです。サービスには何も尋ねられていないので、空の表とは別物です。しかも `2>&1` なしで拾うと見えません。

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

端末に頼めるものの中でいちばん高価です。動いている全プロセスを歩き、それぞれに binder 呼び出しを送り、各プロセスが自分のメモリマップを歩いて自分の値を計算します。CPU の山を見張っているその端末で、数百ミリ秒から数秒の実 CPU を使います。1 秒周期のタイマーに載せないでください。
PSS と RSS は別の量で、同じものとして見せてはいけません。後者は `top` で無料で得られます。
省メモリ構成では PSS の収集が無効なので、節の見出しが RSS 側になっていることがあります。
AOSP は PSS の節より前に RSS の節を印字します（`Total RSS by process:` の後に `Total PSS by process:`）。tag android-11.0.0_r1 から android-15.0.0_r1 までのすべてのリリースでそうなので、ダンプの先頭に RSS の見出しがあるのは普通の並びです。
このダンプは実行中ずっと、凍結されたキャッシュ済みアプリをすべて解凍し、最後にまとめて凍結し直します。タイマーで回すと、報告しているはずのメモリと CPU の状況そのものを変えてしまいます。

これには UI があります

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

Android System Monitor を開く

コマンド	何をするか
top	1 回分のプロセス表：CPU 使用率、メモリ、状態、コマンドライン。
am force-stop	あるアプリのプロセスとサービスをすべて終了させます。
dumpsys battery	バッテリーサービスの現在の状態：残量、充電状態、健康度、電圧、温度。

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

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

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