ByteScope

Android ADB Toolbox

Eleven small adb jobs as buttons — wireless debugging, screenshots, text input, deep links, screen sizes, proxies, properties and crash logs.

Every command runs over the USB cable and its output stays in this tab. Nothing is uploaded, and screenshots or exports are written by your browser straight to your own disk.

Checking browser support…

Wireless debugging (adb over Wi-Fi)

Switch the phone's ADB daemon to TCP port 5555 and get the connect command for a desktop terminal. Both devices have to be on the same network, and the switch is forgotten when the phone reboots.

adb tcpip 5555

Connect a phone to use this section. The command above works in any shell.

Screenshot

Takes a PNG with the phone's own screencap and pulls it back over the cable at full resolution. DRM-protected content comes out black, because the compositor will not hand those frames to anyone.

screencap -p

Connect a phone to use this section. The command above works in any shell.

Send text and key presses

Types into whatever has focus on the phone, using the same input text the platform gives adb. Handy for long passwords, URLs and test data you do not want to thumb in.

input text 'hello world' input keyevent 3

Connect a phone to use this section. The command above works in any shell.

Fake screen size and density (wm size)

Makes the phone pretend to be a different screen, which is the cheapest way to see your layout at another breakpoint on real hardware. A breakpoint reacts to dp — pixels times 160 divided by dpi — so every preset sets both.

wm size 1080x2340 wm density 420 wm size reset wm density reset

Connect a phone to use this section. The command above works in any shell.

Developer switches

The switches from the phone's Developer options, without walking through six menus: animation speeds, touch feedback, pointer coordinates, do-not-keep-activities and forced right-to-left layout.

settings put global window_animation_scale 0.0 settings put system show_touches 1

Connect a phone to use this section. The command above works in any shell.

Device proxy (mitmproxy, Charles, Fiddler)

Points the phone's HTTP stack at a proxy on your machine, which is the one-line version of the wiring every traffic-capture tutorial starts with. Clearing it is one press and is the first button here for a reason.

settings put global http_proxy 10.0.0.5:8080 settings put global http_proxy :0

Connect a phone to use this section. The command above works in any shell.

System properties (getprop)

The whole property table — usually over a thousand entries — searchable, with the fifteen that answer what is this device pinned on top. Nothing typed here reaches the phone: the search runs in this tab.

getprop

Connect a phone to use this section. The command above works in any shell.

A debuggable app's databases

Lists the SQLite files in a debug build's private data directory and pulls one back, without root. This is the useful half of run-as: the shell cannot read an app's data, but the app's own uid can, and run-as lends you that uid for one command.

run-as com.example.app ls -l databases run-as com.example.app cat 'databases/app.db'

Connect a phone to use this section. The command above works in any shell.

Recent crashes and ANRs

Reads DropBoxManager, the platform's own ring buffer of things that went wrong: app crashes, ANRs, native crashes, Log.wtf calls and kernel tombstones, with their timestamps.

dumpsys dropbox dumpsys dropbox --print data_app_crash

Connect a phone to use this section. The command above works in any shell.

Screen recording

Recording lives with the mirror rather than here, because both are about the display and one implementation of screenrecord is safer than two — the process has to be stopped on every path, or it keeps encoding with nobody watching.

screenrecord --time-limit 180 --bit-rate 20000000 /sdcard/out.mp4

Record the screen on the screen mirror page →

What a browser cannot do with ADB

Not a list of features waiting to be built. These are things the platform or the browser sandbox makes impossible, and the reasons are worth knowing before you go looking for a workaround.

  • adb forward / adb reverse

    Port forwarding needs a TCP listener, and a web page cannot be one. A tab has no server socket in any browser, by design — so there is nowhere for localhost:8080 on your machine to point. The desktop adb keeps this one.

  • adb backup / adb restore

    adb backup was deprecated in Android 12 and most apps opted out of it long before that with allowBackup=false, so what it produces on a modern phone is a nearly empty archive. Pulling the files you actually want is what the file browser does.

  • fastboot

    Fastboot is a different protocol on a different USB interface, spoken by the bootloader rather than by Android. It is implementable over WebUSB, but nothing in the ADB code path helps, so it belongs in a tool of its own rather than as a checkbox here.

  • input text (non-ASCII)

    input text can only produce characters the virtual keyboard key map knows, which is printable ASCII. This is a limit of the platform command: a desktop adb cannot type Japanese either.

  • adb root / su

    adb root only works on an engineering or userdebug build, and su only exists on a rooted phone. Everything on this page is built to work without either, which is also why some of it politely refuses.

Everything else on this page runs through the ordinary ADB shell, on an ordinary retail phone, with USB debugging switched on and nothing installed.

About this tool, FAQ and related tools

About this tool

Plug an Android phone into a Chromium browser over USB and this page gives you eleven of the adb shell commands you keep looking up, as buttons with their output parsed: switch the daemon to Wi-Fi, take a screenshot with a status bar that shows none of your business, type text and press hardware keys, fire a deep link and read the launch result, pretend the screen is another size, flip the developer switches, point the phone at a debugging proxy, search all twelve hundred system properties, pull a debug build's own databases, and read the recent crashes and ANRs. Every section shows the exact command it runs, so you can take it away and use it in a terminal. Nothing is installed on the phone and nothing is uploaded — this is a static page with no server behind it.

Wireless debugging, and the one thing a browser cannot do

This page can switch the phone's ADB daemon to TCP port 5555 and read the phone's own IP address, because both of those travel over the USB connection it already has. What it cannot do is then connect to that port. A web page has no raw TCP socket: fetch speaks HTTP and the ADB handshake is not HTTP, WebSocket needs a WebSocket server on the far end and the ADB daemon is not one, and WebTransport needs a QUIC endpoint that is not one either. There is no flag, no permission prompt and no origin trial that changes this; it is the sandbox working as intended. So the honest shape of the feature is a wizard that flips the switch and hands you adb connect 192.168.1.23:5555 for a desktop terminal — and the same reasoning is why you will never see adb forward here.

Screenshots without your notifications in them

screencap -p takes the picture and the bytes come back over the cable at full resolution, which is already better than a phone screenshot you then have to transfer somehow. The part worth knowing about is next to it: SystemUI's demo mode, the platform's own feature for freezing the status bar at a fixed clock, a full battery with no charging bolt, full signal and no notification icons. It is how store listings are made. Two things are easy to get wrong and this page handles both — the mode is ignored unless sysui_demo_allowed is switched on, so the page probes that setting rather than firing broadcasts into the void, and a phone left in demo mode keeps showing a fake clock until something exits it, so the exit button is always visible.

Typing on the phone, and why Chinese is impossible

input text is the most delicate command on this page, because the string being sent is yours and it crosses two interpreters: a device shell, where a; reboot would be two commands, and input itself, which turns %s into a space before anything reaches the keyboard. So the text is emitted as a single-quoted word — inside which a space, &, ;, $, a backtick and a pipe are all literal bytes — with three exceptions handled explicitly: an apostrophe is typed as a key event rather than escaped, a line break becomes Enter, and a % before an s is split into its own command so the platform cannot eat it. What cannot be fixed is the character set. input text ends in a virtual-keyboard key map that only knows printable ASCII, so Japanese, Chinese and accented letters produce nothing. That is a limit of the ADB command; a desktop adb cannot type them either.

Deep links, and what the -W flag actually tells you

am start -W -a android.intent.action.VIEW -d <url> is the fastest way to answer whether your intent filter really claims a URL, and the page reads the reply properly: Status: ok with the activity that won and the launch times, or unable to resolve Intent — which is its own answer, not an error, and usually the one you were testing for. Two subtleties are worth stating. A URL is exactly the kind of string that legitimately contains an ampersand and a question mark, and an unquoted ampersand backgrounds the command and silently drops half the query — the classic reason a hand-typed deep-link test appears not to work. And when the app was already in front, the phone prints a warning and no timings at all; this page says so rather than showing you a reassuring 0 ms.

Faking a screen size, and the way back

wm size 1080x2340 and wm density 420 make the phone pretend to be a different screen, which is the cheapest possible way to see your layout at another breakpoint on real hardware. Because a breakpoint reacts to density-independent pixels — pixels times 160 divided by dpi — every preset here sets both numbers and is labelled with the dp width it produces: 320, 360, 411, 480, 800. Now the warning, and it is the real one on this page. An override persists across a reboot and changes the size *everything* is drawn at, including the Settings app you would use to undo it; a wrong density can leave buttons off the edge of the screen and a phone you cannot fix from the phone. So the restore button sits next to the presets at all times, the confirmation dialog shows wm size reset and wm density reset before anything runs, and both work whether or not this page was what set the override.

The developer switches, and the proxy you will forget

Animation scales, show taps, pointer location, don't-keep-activities and forced right-to-left layout are all a settings put away, and this page reads each current value *before* writing so the undo command it records is the value that was actually there. The proxy is the same mechanism and a much bigger footgun: settings put global http_proxy 10.0.0.5:8080 points the phone's HTTP stack at mitmproxy or Charles on your laptop, and if you walk out of the building with it still set, the phone has no working internet anywhere — not on another Wi-Fi network, not on mobile data — and nothing on the phone explains why. That is why clearing it is the first button in that section rather than the last, why settings put global http_proxy :0 is shown as the antidote, and why the clear button works on a proxy this page never set.

Properties, app databases, and the crash log

The last three sections are read-only and are where a debugging session usually ends up. The property browser searches all of getprop — over a thousand entries on a modern phone — with the fifteen that answer what this device is pinned on top, and a JSON export that sorts its keys so two phones diff cleanly. The app-database section uses run-as, which lends the shell an app's own uid for one command, so a debug build's SQLite files can be listed and pulled without root; a release build is refused by the platform, and the page says which of those two you are looking at rather than printing a generic failure. And the crash section reads DropBoxManager, which is the real answer to how you read ANR traces without root: /data/anr is not readable by the shell user on a modern build, but the same traces are in the drop box, and dumpsys will hand them over.

None of this is a substitute for platform-tools on your own machine — a terminal is faster once you know the commands, and this page will happily show you what they are. What it is good for is the phone that is not yours, the machine that is not yours, and the five minutes in which installing an SDK is not on the table. From here, the Web ADB hub has the device dashboard and the rest of the family, the logcat viewer shows what the phone was saying while you poked at it, and the screen page mirrors or records the display.

Frequently asked questions

How do I use wireless debugging from the browser?

Press the switch here and the phone's ADB daemon starts listening on TCP 5555; the page reads the phone's Wi-Fi address and gives you `adb connect <ip>:5555` to paste into a terminal on your computer. The connection itself has to be made by a desktop `adb`, because a browser tab has no raw TCP socket — and no flag changes that. Both devices need to be on the same network, and the switch is forgotten when the phone reboots, so next time you plug in you can simply do it again. To go back to USB-only debugging, run `adb usb` or reboot the phone.

Why can't I type Chinese or Japanese with input text?

Because `input text` cannot. The command ends in Android's virtual-keyboard character map, which only has keys for printable ASCII, so anything outside that range produces no key events at all — on some builds it fails loudly, on others it silently types nothing. This is a limitation of the platform command rather than of USB, of the browser, or of this page: a desktop `adb shell input text` cannot type them either. The practical answer is a keyboard app on the phone, or the clipboard. This page refuses non-ASCII up front and names the character it cannot send.

How do I clear an ADB proxy I set on my phone?

`settings put global http_proxy :0` — and the clear button in the proxy section does exactly that, whether or not this page is what set it. The `:0` matters: an empty string is stored literally on several builds and leaves the phone still pointing at nothing useful, while `:0` is what the platform's own settings UI writes. It is worth doing before you unplug, because a phone that leaves the building with a proxy set has no working internet on any network and gives no hint as to why. The setting is global, so it applies on mobile data as well as on Wi-Fi.

What is Android demo mode and why is my status bar unchanged?

Demo mode is a documented SystemUI feature that freezes the status bar at a fixed clock, 100% battery with no charging bolt, full signal and no notification icons — it exists so that screenshots for store listings do not also show your unread messages. If nothing happens when you send it, the usual reason is the gate: SystemUI ignores every demo broadcast unless `sysui_demo_allowed` is 1, which is not the default. This page probes that setting and offers to turn it on with the way back recorded. The other reason is a manufacturer who removed the receiver, which no amount of broadcasting fixes.

Why does run-as say my app is not debuggable?

Because it is a release build, and `run-as` only lends you an app's uid when that app's manifest marks it debuggable. Every app from the Play Store is a release build, so this section works on what you compile rather than on what you install. There is no way around it from a shell: reading another app's private data needs either a debuggable build of that same app or a rooted phone. If the message instead says the package is unknown, the name is wrong, or the app is installed for a different user or work profile than the one you are looking at.

Related tools