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 package

読み取りのみ

パッケージマネージャが知っているすべて：バージョン、パス、flags、インストール元、ユーザーごとの状態。

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

構文

dumpsys package [<package>]

フラグと引数

トークン	意味
<package>	ダンプを 1 パッケージに絞ります。それでもリゾルバの表は印字され、そこには他のパッケージも出てきます。

使用例

```
dumpsys package com.example
```
アプリ 1 つのバージョン、インストール日時、インストーラ、flags。
```
pm list packages -f -U --show-versioncode
```
棚卸しだけが目的なら、こちらの方がずっと安価です。

出力の読み方

出力例

Packages:
  Package [com.example] (a1b2c3d):
    appId=10234
    codePath=/data/app/~~kO7bJ9w==/com.example-Ay8s2Q==
    versionCode=4711 minSdk=24 targetSdk=34
    versionName=1.2.3
    flags=[ SYSTEM HAS_CODE ALLOW_CLEAR_USER_DATA ]
    lastUpdateTime=2024-03-14 12:34:56
    installerPackageName=com.android.vending
    User 0: ceDataInode=1234 installed=true hidden=false stopped=false enabled=0

`Package [名前]` ブロックの中に字下げされた `key=value` が並び、その後に Android ユーザーごとの `User N:` 行が続きます。パッケージは正当に 2 回現れ得ます。更新されたシステムアプリは `Packages:` の下に現行のブロックを、`Hidden system packages:` の下に工場出荷時のコピーを持ち、後に来た方を読むと出荷時のバージョンをインストール済みとして報告してしまいます。その 2 つ目のブロックが存在すること自体が「これは更新済みシステムアプリ」を示す最も確実な合図です。

出力フィールド

フィールド	意味
versionCode / versionName	インストール済みのバージョン。整数と表示用の文字列。
codePath	APK セットの場所。
flags=[ … ]	アプリケーションの flags。debloat の判断が懸かるのは `SYSTEM` です。
installerPackageName	インストールした主体。プリインストールアプリでは `null` という 4 文字。
firstInstallTime / lastUpdateTime	端末自身のタイムゾーンでの壁時計。オフセットは印字されません。
User N: … enabled=	0 default、1 enabled、2 disabled、3 ユーザーによる無効、4 使うまで無効。

必要な権限

パッケージマネージャのダンプ binder は `DumpUtils.checkDumpAndUsageStatsPermission` を `PackageManager` というタグで呼ぶので、`android.permission.DUMP` と `android.permission.PACKAGE_USAGE_STATS` を求めます。どちらも Shell パッケージのマニフェストにあり、usage-stats のチェックは app-op に至る前に `SHELL_UID` を短絡するため、素の認可済み `adb` 接続で全部見えます。root も `adb root` も設定画面での許可も、パッケージ単位の許可もありません。このダンプはシステムアプリでもサイドロードしたアプリでも同じレコードを読みます。罠はアクセスではなく引数の解析で、打つ前に知っておく価値があります。`DumpHelper` が引数をパッケージ名だと判断するのは、それが `android` という文字列そのものか、**ドットを含む** ときだけです。それ以外は節のキーワード一覧――`p`、`perm`、`pref`、`prov`、`s`、`f`、`l`、`installs`、`dexopt`、`known-packages`、`protected-broadcasts` ほか 20 個ほど――と照合されます。つまりドットの無い引数は「そんなパッケージは無い」とは言われません。どれかの節に当たってまったく別のものを出すか、どれにも当たらずに巨大な既定のダンプが走り続けるかのどちらかです。必ず完全なパッケージ名を渡してください。それが出力を小さく保つ唯一の手段でもあります。絞り込まない形は端末が出すダンプの中でも最大級です。Android Debloat Tool が必ずパッケージ名を指定するのも同じ理由です。

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

メッセージ	意味
Unable to find package: com.exmaple	スナップショットにその名前のパッケージ状態が無く、APEX でもなかったので、ダンプはこの行だけを出して即座に返りました。標準出力の行で、しかも 3 つの違う状況に対する同じ答えです。打ち間違い、アンインストール済み、そして別の Android ユーザーにだけ入っているアプリ。最後の 1 つを前の 2 つと切り分けるのは `pm list packages --user 10` です。
Unknown argument: --full; use -h for help	`DumpHelper` が知らないオプションです。これを出したうえで止まらずに続行するので、ダンプの残りはそのまま現れ、意図したフラグだけが無視されます。危ないのは、絞り込みが効いたつもりで既定のダンプを読んでしまうことです。受け付けられるオプションは `-a`、`-f`、`-h`、`--checkin`、`--all-components`、`--include-apex`、`--proto` です。
Permission Denial: can't dump PackageManager from from pid=4821, uid=10231 due to missing android.permission.DUMP permission	`DumpUtils` が出す行で、標準出力に、パッケージのブロックの代わりに書かれます。`from from` の重複は本物の AOSP のテキストです。普通の `adb shell` からこれが出ることはありません。出たなら呼び出し元が uid 2000 ではなかったということで、ケーブル越しならほぼ確実に `run-as` の中で実行してアプリの資格を引き継いでいます。
* SERVICE 'package' DUMP TIMEOUT (10000ms) EXPIRED *	`dumpsys` の既定の 10 秒が尽きました。絞り込まない `dumpsys package` は端末上で最大級のダンプで、締め切りに収めているのは普通、パッケージ名の指定です。ここで切れると特に危険なのは、`Hidden system packages:` が現行のブロックより後に来るからです。末尾を失うことは、それが更新済みシステムアプリだという証拠を失うことです。

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

タイムスタンプにタイムゾーンはありません。端末上で整形されたものです。自分の機械で変換すると黙って自分のタイムゾーンが当てられ、旅をした端末では 1 日ずれ得ます。
`firstInstallTime` は移動しました。Android 12 以前は `lastUpdateTime` の隣、Android 13 以降は `User N:` 行の下に字下げしてユーザーごとに印字されます。
欠けている文字列は `null` という 4 文字で印字されます。実在のパッケージ名やパスがそう綴られることはありません。

これには UI があります

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

Android Debloat Tool を開く

コマンド	何をするか
pm list packages	インストール済みパッケージを一覧表示します。APK パス、uid、バージョンコード、インストーラも同時に取得できます。
pm path	インストール済みパッケージを構成する APK ファイルの絶対パスを表示します。
pm disable-user	パッケージを削除せずに、指定した Android ユーザーで無効にします。アンインストールより安全で、確実に戻せます。
pm uninstall	パッケージを削除します。ユーザー単位の削除なら、root なしでプリインストールアプリを片付けられます。

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

コマンド	何をするか
dumpsys battery	バッテリーサービスの現在の状態：残量、充電状態、健康度、電圧、温度。
dumpsys diskstats	パーティションごとの空き容量、ディスク書き込み遅延の実測、そしてキャッシュされたアプリ別の使用量内訳。
dumpsys thermalservice	端末が発熱で性能を絞っているか、そしてハードウェア層が報告する各温度ゾーンを摂氏で表示します。
dumpsys sensorservice	端末にあるすべてのセンサーとそのベンダー、type、レート、バッチング。加えて直近の測定値のバッファ。
dumpsys meminfo	どのプロセスがメモリを最も使っているかを、PSS（比例配分したサイズ）で表示します。
dumpsys activity activities	いまどのアプリが前面にいるか、そしてその背後のタスクとスタックの構造。
dumpsys dropbox	クラッシュ、ANR、tombstone を保持するプラットフォームのリングバッファ。root なしで ANR トレースを読む方法です。

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