ByteScope

dumpsys dropbox

読み取りのみ

クラッシュ、ANR、tombstone を保持するプラットフォームのリングバッファ。root なしで ANR トレースを読む方法です。

コマンド
adb shell dumpsys dropbox
コマンド
システムサービス(dumpsys)
リスク
読み取りのみ

構文

dumpsys dropbox [--print <tag>]

フラグと引数

トークン意味
--print <tag>その tag のエントリの本文をすべて印字します。tag なしなら索引だけで、最初に見るべきはそちらです。

使用例

  • dumpsys dropbox

    索引:1 エントリ 1 行、本文なし。安価です。

  • dumpsys dropbox --print data_app_anr

    実際の ANR トレース。スタックも入っています。

  • dumpsys dropbox --print data_app_crash

    直近のアプリのクラッシュと、その例外。

出力の読み方

出力例

Drop box contents: 96 entries
Max entries: 1000

2026-07-26 11:04:31 data_app_crash (text, 4321 bytes)
2026-07-26 11:41:02 data_app_anr (compressed text, 12043 bytes)
2026-07-26 12:00:00 SYSTEM_TOMBSTONE (data, 91234 bytes)

索引はタイムスタンプ、tag、そしてエントリの保存形式についての括弧書きです。tag が分類で、`data_app_*` は使用者が入れたアプリ、`system_app_*` はプリインストール、`*_anr` は応答なしのトレース、`*_crash` は Java の例外、`*_native_crash` と `SYSTEM_TOMBSTONE` はネイティブのクラッシュです。括弧の中身は自由書式で、メーカーは言い換えます。

出力フィールド

フィールド意味
Drop box contents: N entriesいまバッファが保持しているエントリ数。
<date> <time> <tag>端末自身のタイムゾーンでの発生時刻と、どの種類の失敗か。
(text, N bytes)保存形式とサイズ。読めないサイズは 0 ではなく不明です。
data_app_anr使用者が入れたアプリでの ANR。/data/anr に探しに行っていたトレースです。
SYSTEM_TOMBSTONEシステムが保持することを選んだネイティブのクラッシュ。

必要な権限

認可済みの `adb` 接続だけで足ります。root も `adb root` も `su` も要らず、USB デバッグ以外に開発者向けオプションで入れるものもありません。このコマンドが行き着く `DropBoxManagerService.dump` は、いちばん最初の文が `DumpUtils.checkDumpAndUsageStatsPermission(getContext(), TAG, pw)` で、関門は `android.permission.DUMP` と `android:get_usage_stats` app-op の組み合わせです。そして `shell` ユーザーの正体である `com.android.shell` は、自身のマニフェストで `android.permission.DUMP` と `android.permission.PACKAGE_USAGE_STATS` の両方を与えられています。このページが存在する理由はまさにその非対称です。drop box は shell が既に持っている権限で読めるのに、`/data/anr` は持っていないファイル権限の向こうにあり、同じトレースが一方からは届いて一方からは届きません。言葉の出口から実務上の帰結が 2 つ出ます。拒否は dump 自身が使うのと同じ `PrintWriter` に書かれるので、標準エラーではなくエントリに混ざって標準出力に落ちます。tag を grep するスクリプトは単に何も見つけられず、端末は健康だと結論します。一方 `dumpsys` 自身の「service not found」の行は標準エラーへ行きます。両方の stream を残し、短い答えを信じる前に最初の 1 行を読んでください。

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

メッセージ意味
Permission Denial: can't dump DropBoxManagerService from from pid=4021, uid=2000 due to missing android.permission.DUMP permission`DumpUtils.checkDumpPermission` がこの行を組み立てて false を返すので、`dump` はエントリを 1 件も並べる前に止まります。`from from` と重なっているのは上流自身の typo で、行を照合するなら直さずそのまま写してください。普通の端末でこれが出るなら、バッファが空なのではなく、何かが `com.android.shell` から `android.permission.DUMP` を剥がしています。dump 自身の writer に書かれるので、他の出力と一緒に標準出力で見つかります。
Can't find service: dropbox`dumpsys` が service manager に `dropbox` を尋ねて何も返らず、サービスを呼ばないまま `NAME_NOT_FOUND` を返しました。起動途中、`system_server` がサービスを公開する前なら想定内です。この行は標準エラーに書かれるので、標準エラーを捨てる取り方だと、空でしかも成功したように見える実行になります。
(No entries found.)サービスは答えて、何も一致しませんでした。`dump` は最後まで一致数が 0 のままならこれを印字します。おろしたての端末も、あなたが指定した日付や tag のフィルタが何にも当たらなかった場合も、どちらもここに来ます。エラーではなく本物の答えなので、この端末は一度もクラッシュしていないと結論する前にフィルタを見直してください。
(contents lost)索引はまだそのエントリを覚えていますが、本文は消えています。そのレコードは `IS_EMPTY` フラグを持っていて、`dump` はすぐ次へ進みます。その tag を `--print` してもヘッダだけが並び、下にスタックはありません。よくある原因はバッファがサイズ上限を守るためにファイルを間引いたことで、復元する手段はありません。クラッシュは後回しにせず早めに回収してください。
*** SERVICE 'dropbox' DUMP TIMEOUT (10000ms) EXPIRED ***`dumpsys` が待つのをやめました。10 秒が組み込みの持ち時間で、`-t <seconds>` で伸ばせます。何週間も起動しっぱなしの端末で忙しい tag を `--print` するのが、現実的にこれを踏む方法です。手元にあるのは完全な dump ではなく切り詰められた先頭部分なので、届いた末尾を信じるのではなく tag を絞るかタイムアウトを伸ばしてください。

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

  • 最近のビルドでは `/data/anr` は shell ユーザーから読めません。だからこれが「root なしで ANR トレースを読む方法」の答えになります。同じトレースが drop box にあり、dumpsys が渡してくれます。
  • tag なしで `--print` を実行しないでください。1 か月動いていた端末では出力が数十メガバイトになり得ます。
  • tag は列挙されたものではなく慣習で、ベンダーは独自のものを追加します。見慣れない tag も読むことはできて、分類だけができません。

これには UI があります

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

Android ADB Toolbox を開く

関連コマンド

dumpsys dropbox と同じ作業で出てくるコマンド。

コマンド何をするか
logcatシステムログを流し読みします。端末で起きていることすべての実況です。
dumpsys activity activitiesいまどのアプリが前面にいるか、そしてその背後のタスクとスタックの構造。
run-asあるアプリ自身の uid でコマンドを実行します。root なしで debuggable ビルドのプライベートファイルを読む方法です。

他のシステムサービス(dumpsys)コマンド

コマンド何をするか
dumpsys batteryバッテリーサービスの現在の状態:残量、充電状態、健康度、電圧、温度。
dumpsys diskstatsパーティションごとの空き容量、ディスク書き込み遅延の実測、そしてキャッシュされたアプリ別の使用量内訳。
dumpsys thermalservice端末が発熱で性能を絞っているか、そしてハードウェア層が報告する各温度ゾーンを摂氏で表示します。
dumpsys sensorservice端末にあるすべてのセンサーとそのベンダー、type、レート、バッチング。加えて直近の測定値のバッファ。
dumpsys meminfoどのプロセスがメモリを最も使っているかを、PSS(比例配分したサイズ)で表示します。
dumpsys packageパッケージマネージャが知っているすべて:バージョン、パス、flags、インストール元、ユーザーごとの状態。

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

よくある質問

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 はブラウザでは一切動きません。

打つより押したい場合は、Web ADB Toolkit がこの種のコマンドをブラウザから USB 経由で実行します。あるいは全コマンドを見る。