How do I run an adb shell command?

Switch on developer options and USB debugging on the phone, plug it in, then run adb shell from a machine with platform-tools installed — or run adb shell on its own to get an interactive prompt and type the command without the prefix. If the command produces binary output, such as a screenshot, use adb exec-out instead of adb shell: the plain shell service attaches a terminal, which rewrites newline bytes and corrupts the data.

Do adb shell commands need root?

Not the ones on this reference. They run as the shell user, which can manage packages for its own Android user, read most dumpsys services, write the settings provider, inject input and read shared storage. Root is only needed for things this reference deliberately avoids — reading another app's private data (except through run-as on a debuggable build), writing system partitions, or reading /data/anr directly.

Why does the output look different on my phone?

Either the Android version or the manufacturer. Some flags and fields arrived in a specific release, and those are noted per command. The rest is OEM patching, which hits dumpsys hardest: a dump is debug output whose text is whatever the service author last printed, and manufacturers change it and backport their changes. Read fields by name rather than by position, and treat an unfamiliar shape as a difference rather than as a failure.

Can I run this from a browser instead of a terminal?

For many commands, yes — the Web ADB tools on this site talk to a phone over WebUSB from a Chromium-based desktop browser, with no SDK installed and nothing uploaded. Each page links to the tool that runs its command, when one exists. Two limits are worth knowing: only one program can hold the ADB interface at a time, so a desktop adb server has to be stopped first, and adb forward and adb reverse cannot work in a browser at all.

wm density

changes the device

Reports the display density, or overrides it — which is what actually moves a layout breakpoint.

Command: adb shell wm density
Commands: Display and capture
Risk: changes the device

Syntax

wm density [<dpi> | reset]

Flags and arguments

Token	Meaning
<dpi>	The density to report. Android's own buckets run from 120 to 640, and vendors ship values in between.
reset	Drop the override and go back to the physical density.

Examples

```
wm density
```
Report only.
```
wm density 420
```
With `wm size 1080x2340`, this is a 411 dp wide phone — a real breakpoint.
```
wm density reset
```
Undo.

Reading the output

Sample output

Physical density: 560
Override density: 420

Same shape as `wm size`: the physical value always, the override only while one is set. The number that decides which layout you get is dp, so the useful quantity is width in pixels times 160 divided by this dpi — 1080 px at 420 dpi is 411 dp, and the same 1080 px at 320 dpi is a 540 dp tablet-ish layout.

Output fields

Field	Meaning
Physical density	The panel's real dpi.
Override density	What is being reported instead. Present only while an override is set.

What access it needs

No root and no `adb root`. `wm` is a one-line shell script that runs `cmd window "$@"` (AOSP `cmds/wm/wm.sh`), and the calls an override goes through, `setForcedDisplayDensityForUser` and `clearForcedDisplayDensityForUser`, are annotated `@EnforcePermission(android.Manifest.permission.WRITE_SECURE_SETTINGS)` — a permission `com.android.shell` is granted in its own manifest, so an authorised cable is enough and no developer-options switch beyond USB debugging is involved. There is one asymmetry worth carrying with you: the density calls take a user id and the shell command passes `USER_CURRENT`, while the size calls take no user at all. A density override is therefore recorded against whoever is in the foreground, and a phone with a second user or a work profile can show the override on one and not the other; a size override has no such dimension. The other half is a bound rather than a permission. The shell command refuses anything below 72 before it calls the window manager, and it has no upper limit at all — the range this site enforces is its own sanity check, not the platform's, because the platform will cheerfully accept a density that leaves one and a half buttons on the screen.

Failure messages, decoded

Message	Meaning
Error: density must be >= 72	The lower bound is checked in `runDisplayDensity` itself, before the window manager is called, so nothing changed. Note where the check is not: there is no matching upper bound, so a fat-fingered `4200` is accepted and applied. Keep `wm density reset` on screen before you experiment.
Error: bad number	Printed with the exception's own `toString()` appended, naming the token that failed. Unlike `wm size`, this argument is parsed as a plain integer — there is no `dp` or `px` suffix handling here — so `420dpi` is a syntax error rather than a clever way to say 420.
Error: the uniqueId is invalid	The `-u <uniqueId>` form was given an id the display manager does not know, and the command returns without reading or setting anything. The trailing space before the line ends is upstream's own, so match on the text, not on the whole line.
Remote exception:	The reporting path could not reach the window manager and printed this plus the exception instead of a density. Treat it as "unknown", never as 0 — a dpi of 0 propagated into a dp calculation divides by zero, which is how a display probe turns one failed read into a page full of nonsense.
cmd: Can't find service: window	`cmd` could not find the `window` service to hand the subcommand to, because `wm.sh` is only a wrapper around `cmd window`. Expected while the device is still booting, before `system_server` has published it — wait for boot rather than concluding the display has no density.

What it changes, and the way back

Like a size override, this survives a reboot and changes the scale of every interface element on the phone, the Settings app included. A density of 800 on a phone panel leaves about one and a half buttons visible, and you cannot tap your way out of it. `wm density reset` is the way back; keep it to hand before you experiment.

Version and vendor notes

Changing density without changing size, or the other way round, produces a device shape that does not exist. Set both.
0 and absurdly large values are ways to make a screen unreadable rather than ways to test one.

We have a UI for this

Android ADB Toolbox runs this command over USB and parses what comes back — a Chromium browser, no SDK, nothing uploaded.

Open Android ADB Toolbox

Related commands

Commands that turn up in the same session as wm density.

Command	What it does
wm size	Reports the display's resolution, or overrides it so the phone pretends to be a different screen.
screencap	Takes a screenshot, either to a file on the phone or to standard output as PNG.
settings put	Writes a value into the settings provider — the mechanism behind most developer-options tricks.

More Display and capture commands

Command	What it does
screenrecord	Records the screen to an MP4 file on the device.

Checked against AOSP, toybox and kernel sources while writing the parsers behind our Web ADB tools. Where a behaviour genuinely varies by Android version or manufacturer, this page says so instead of giving a number that would be wrong on half the phones out there.