Checking browser support…
Watch the phone's live log over the cable, filter it while it streams, and save what you found.
The log is read over the USB cable and stays in this tab. Nothing is uploaded, and an export is written by your browser straight to your own disk.
Checking browser support…
Plug an Android phone into a Chromium browser over USB and this page streams its log: the same logcat -v threadtime a desktop adb would print, filtered by level, by tag or by a regular expression as the lines arrive, with pause, clear and an export of everything the buffer holds. Nothing is installed on the phone and nothing is uploaded — this is a static page talking to adbd over the cable, and closing the tab ends the stream.
A threadtime line is 07-26 13:37:01.234 1234 1250 I ActivityManager: Start proc, and every field earns its place. The date and time come from the phone's clock at the moment the message was written, to the millisecond, which is what makes two log lines comparable with a stopwatch. 1234 is the process id and 1250 is the *thread* id — the pair is how you tell a main-thread stall from a background worker, and the reason this format is worth its extra width over the default. I is the level. ActivityManager is the tag the writer chose, by convention the class or subsystem. Everything after the colon is the message. The viewer keeps the raw line rather than reformatting it, so anything you copy out of here pastes into a bug report as the phone wrote it.
A log viewer that shows less than you expected is usually correct, and the reasons are worth knowing. Levels: logcat shows verbose upward here, but a release build strips most Log.v and Log.d calls at compile time, so they were never written. Privacy: since Android 4.1 an app can only read its *own* log entries, and the READ_LOGS permission that used to grant more is signature-level — the reason this page can show you everything is that the shell user holds it, not that we found a trick. Rate limiting: logd drops messages from a process that floods it and prints a chatty line saying how many, so a burst genuinely loses lines before they reach anyone. Buffers: the default view is main, system and crash; radio and events are separate rings that logcat -b selects and this page does not read. And filters here apply to lines *as they arrive*, so widening one does not bring back what already went past — clear and start again for that.
There is no reimplementation in between. adb logcat on a desktop opens a stream to adbd and prints what comes back; this page opens the same stream over WebUSB and prints what comes back. The parsing that turns a line into fields for the level and tag filters is ours — a small parser with tests against real recorded output — but the bytes are the phone's own, and an unrecognised line is shown raw rather than swallowed. What the browser cannot do is the part that needs a socket: adb logcat on a remote device over TCP is impossible from a web page, because a page has no raw sockets. USB only, and the support table says so.
A busy phone writes tens of thousands of lines a minute, and a viewer that promised to keep all of them would be promising to grow until the tab dies during exactly the long capture it exists for. So the buffer is a rolling window of the most recent hundred thousand lines, and it counts what it discards: the panel prints how many lines it holds, how many it received and how many it dropped, so an export is never quietly less than it claims to be. The terminal's own scrollback is bounded separately, and the export comes from the buffer rather than from the screen — xterm wraps long lines to the window width, and a saved log should have the phone's line breaks, not your window's.
This is a viewer, not a debugger: it cannot attach to a process, set a breakpoint or make an app log more than it was built to log. What it is very good at is the thing that usually comes first — watching what the phone says while you reproduce a problem, on a machine where you never installed platform-tools. From here, the screen page mirrors or records the display while you do it, the system monitor shows what the CPU and thermals were doing, and the Web ADB hub has the rest of the toolkit and a ⌘K drawer that opens this same viewer over any page.
Type part of the app's tag into the tag box — matching is case-insensitive and on a substring, so `Activity` catches `ActivityManager` and `ActivityThread`. If the app's tags are not predictable, use the regex box, which runs against the whole raw line and therefore also matches the package name where it appears in a message. Filtering by process id is the one thing a desktop does more directly (`adb logcat --pid=`), and the equivalent here is to read the pid column of a line you care about and put it in the regex box.
Three different mechanisms. A release build removed most verbose and debug calls before shipping, so they do not exist to be read. `logd` rate-limits a process that floods the log and reports it with a `chatty` line naming how many it dropped — that loss happened on the phone, not here. And this viewer's own window keeps the most recent hundred thousand lines; when it discards older ones it says how many, right above the terminal, so what you export is never quietly incomplete.
Yes — the export button writes what the buffer holds as a plain `.txt` file through your browser's normal download path, with the phone's own line breaks intact. It exports the buffer rather than the visible scrollback, because the terminal wraps long lines to your window width and keeps fewer of them. If lines were dropped before you exported, the counter above the terminal says how many, so the file's limits are visible rather than implied.
No. The page speaks the ADB protocol itself over WebUSB, so there is nothing to install, no PATH to set and no server to start. The one thing to know is the opposite problem: a desktop `adb` server that is already running holds the USB interface exclusively, and this page cannot claim it until you run `adb kill-server` or unplug and replug. The connection card says so when it happens.
Device dashboard, shell drawer and every other Web ADB tool.
Mirror the screen live, or record it to an MP4 over the same cable.
CPU, memory, thermals and the process table, once a second.