ブラウザの対応を確認中…
ケーブル越しに端末のライブログを眺め、流れている最中に絞り込み、見つけたものを保存する。
ログは USB ケーブル経由で読み取り、このタブの中に留まります。どこにもアップロードせず、書き出しはブラウザがそのままお使いのディスクへ書きます。
ブラウザの対応を確認中…
Android 端末を Chromium ブラウザに USB でつなぐと、このページがそのログをストリーミングします。デスクトップの adb が表示するのと同じ logcat -v threadtime を、届いた行に対してレベル・タグ・正規表現で絞り込みながら流し、一時停止・消去・バッファ全体の書き出しができます。端末には何もインストールせず、どこにもアップロードしません。サーバーのない静的ページが adbd とケーブル越しに話しているだけで、タブを閉じればストリームは終わります。
threadtime の 1 行は 07-26 13:37:01.234 1234 1250 I ActivityManager: Start proc という形で、どの列にも意味があります。日付と時刻はメッセージが書かれた瞬間の端末の時計で、ミリ秒まであるので 2 行の間隔をストップウォッチのように比べられます。1234 はプロセス ID、1250 は**スレッド** ID で、この組み合わせがメインスレッドの詰まりとバックグラウンド処理を区別する手掛かりです。これが既定形式より幅を使う価値のある理由でもあります。I はレベル、ActivityManager は書き手が付けたタグ（慣例としてクラス名かサブシステム名）、コロンの後ろがメッセージです。ビューアーは整形せず生の行を保持するので、ここからコピーしたものはそのままバグ報告に貼れます。
思ったより少なく見えるログは、たいてい正しく動いています。レベル: ここでは verbose 以上を表示しますが、リリースビルドは Log.v や Log.d の多くをコンパイル時に落とすので、そもそも書かれていません。プライバシー: Android 4.1 以降、アプリは**自分の**ログしか読めず、かつて広く読めた READ_LOGS は signature レベルです。このページが全部見せられるのは裏技ではなく、shell ユーザーがその権限を持っているからです。レート制限: logd はログを溢れさせたプロセスのメッセージを捨て、いくつ捨てたかを chatty 行で報告します。つまり突発的な出力は誰の手にも届く前に本当に失われます。バッファ: 既定は main・system・crash で、radio と events は logcat -b で選ぶ別のリングであり、このページは読みません。そして絞り込みは**届いた行**に適用されるので、条件を緩めても既に通り過ぎた行は戻りません。そのときは消去して開始し直してください。
間に作り直したものが何もありません。デスクトップの adb logcat は adbd へのストリームを開いて返ってきたものを表示し、このページは同じストリームを WebUSB 越しに開いて返ってきたものを表示します。レベルとタグの絞り込み用に行を項目へ分解する部分だけが自作（実機出力を録ったテスト付きの小さなパーサー）で、バイト列は端末そのものです。認識できない行は飲み込まず生のまま出します。ブラウザにできないのはソケットが要る部分で、TCP 越しのリモート端末の adb logcat はウェブページには不可能です。ページに生ソケットがないからで、USB のみ。対応表にもそう書いてあります。
忙しい端末は 1 分に数万行を書きます。全部保持すると約束するのは、まさに長時間キャプチャのためにあるこの機能が、そのキャプチャ中にタブを殺すまで膨らむと約束することです。だからバッファは最新 10 万行のローリング窓で、捨てた分を数えます。保持している行数・受け取った行数・捨てた行数をパネルに出すので、書き出しが黙って主張より少なくなることはありません。ターミナル側のスクロールバックは別に上限があり、書き出しは画面ではなくバッファから作ります。xterm は長い行をウィンドウ幅で折り返すので、保存するログには端末の改行が入っているべきです。
これはビューアーであってデバッガーではありません。プロセスにアタッチしたり、ブレークポイントを置いたり、アプリに元々書いていないログを吐かせたりはできません。得意なのは普通いちばん最初にやること、つまり platform-tools を一度も入れていないマシンで、問題を再現しながら端末の言うことを眺めることです。ここからは、画面ページで同時にミラーリングや録画ができ、システムモニターで CPU と温度の様子が見られ、Web ADB ハブには残りのツールと、どのページでもこのビューアーを開ける ⌘K ドロワーがあります。
タグ欄にそのアプリのタグの一部を入れてください。大文字小文字を無視した部分一致なので、`Activity` は `ActivityManager` と `ActivityThread` の両方に当たります。タグが読みにくいアプリなら正規表現欄を使います。こちらは生の行全体に対して走るので、メッセージ中に現れるパッケージ名にも当たります。プロセス ID での絞り込みはデスクトップのほうが直接的（`adb logcat --pid=`）で、ここでは気になる行の PID 列を読んで正規表現欄に入れるのが等価な操作です。
別々の仕組みが 3 つあります。リリースビルドは出荷前に verbose と debug の多くを削っているので、読む対象として存在しません。`logd` はログを溢れさせたプロセスにレート制限をかけ、いくつ捨てたかを `chatty` 行で報告します。この損失は端末側で起きたもので、ここではありません。そしてこのビューアー自身の窓は最新 10 万行を保持し、古い行を捨てるときはターミナルのすぐ上に何行捨てたかを出します。だから書き出したものが黙って不完全になることはありません。
できます。書き出しボタンがバッファの内容を、端末自身の改行を保ったまま普通の `.txt` としてブラウザの通常のダウンロード経路で保存します。画面のスクロールバックではなくバッファを書き出すのは、ターミナルが長い行をウィンドウ幅で折り返し、保持する行数も少ないからです。書き出しの前に捨てられた行があれば、ターミナルの上のカウンターが何行かを示すので、ファイルの限界は暗黙ではなく目に見えます。
不要です。このページ自身が WebUSB 越しに ADB プロトコルを話すので、入れるものも、通す PATH も、起動するサーバーもありません。知っておくべきは逆の問題です。すでに動いているデスクトップの `adb` サーバーが USB インターフェイスを排他的に押さえていると、`adb kill-server` を実行するか抜き差しするまでこのページは掴めません。そうなったときは接続カードがそう言います。
デバイスのダッシュボード、shell ドロワー、その他すべての Web ADB ツール。
同じケーブルで画面をリアルタイムにミラーリング、または MP4 に録画。
CPU・メモリー・温度・プロセス一覧を 1 秒ごとに。