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 size

changes the device

Reports the display's resolution, or overrides it so the phone pretends to be a different screen.

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

Syntax

wm size [<width>x<height> | reset]

Flags and arguments

Token	Meaning
<width>x<height>	Ask the display to report this resolution instead of its own.
reset	Drop the override and go back to the physical resolution.

Examples

```
wm size
```
Report only. No argument means no change.
```
wm size 1080x2340
```
Pretend to be a 1080p phone.
```
wm size reset
```
Undo. Learn this one before you need it.

Reading the output

Sample output

Physical size: 1440x3120
Override size: 1080x2340

One line, or two. The override line is printed **only when an override exists**, which is the whole subtlety — its presence is how you know the phone is pretending, and its value is the size that layouts actually see. The physical line never changes.

Output fields

Field	Meaning
Physical size	What the panel really is.
Override size	What the display is reporting instead. Present only while an override is set.

What access it needs

No root and no `adb root`, but an override does need a real platform permission behind it. `wm` is a one-line shell script that runs `cmd window "$@"` (AOSP `cmds/wm/wm.sh`), and the two window-manager calls an override goes through, `setForcedDisplaySize` and `clearForcedDisplaySize`, are annotated `@EnforcePermission(android.Manifest.permission.WRITE_SECURE_SETTINGS)`. `com.android.shell` — the package the `shell` user runs as — is granted `android.permission.WRITE_SECURE_SETTINGS` in its own manifest, so an authorised cable is enough, and nothing in developer options gates this beyond USB debugging itself. Reporting is the free half: `wm size` with no argument only reads, which is why it is the command to run and record before you set anything. Two traps live in the plumbing rather than in the permission. The parser looks for a lowercase `x` with `indexOf`, and it accepts `px` and `dp` suffixes on each dimension — so `411dpx731dp` is a valid way to ask for a device-independent shape, while `1080pxx2340px` is not, because the `x` in the first `px` is the one it splits on. And the two size lines go to stdout while every `Error:` goes to stderr, so a script keeping only stdout sees an empty answer where a refusal actually happened.

Failure messages, decoded

Message	Meaning
Error: bad size 1080X2340	The argument had no lowercase `x`, or had one at the very start or very end. `runDisplaySize` refuses before calling the window manager, so nothing changed. A capital `X`, a `*`, or a locale's multiplication sign all land here — as does `1080x` from a truncated variable.
Error: bad number	Printed with the exception's own `toString()` appended, so the full line names the token it could not read. One dimension was not an integer after its optional `px` or `dp` suffix was removed. `1080pxx2340px` is the surprising member of this set: the split lands inside the first `px`, leaving `1080p` to be parsed as a number. Nothing changed.
Remote exception:	The reporting path could not reach the window manager and printed this plus the exception, instead of a size, on stdout. It is the reason this site's parser returns "unknown" rather than a number: anything that is not a `Physical size:` line must not be turned into a resolution, and 0x0 is the worst possible guess.
Exception occurred while executing 'size':	The shell-command handler caught a `Throwable`; the next line names it. A `java.lang.SecurityException` here means the caller lacks `WRITE_SECURE_SETTINGS`, which on a stock build should not happen from `adb shell` — treat it as a modified build rather than as a bad argument. The override was not applied.
cmd: Can't find service: window	`cmd` could not find the `window` service, because `wm.sh` is only a wrapper around `cmd window`. Expected while the device is still booting, before `system_server` has published it. Nothing was read and nothing was set.

What it changes, and the way back

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 value can leave controls off the edge of the screen and a phone you cannot fix from the phone. `wm size reset` puts it back, and it works whether or not the override was set from here — so keep that command visible before you set anything.

Version and vendor notes

Set a density at the same time. A layout breakpoint reacts to density-independent pixels — pixels times 160 divided by dpi — so changing the resolution alone tests a shape no real device has.
Nothing here reports a failure usefully: a refusal comes back as a remote-exception line rather than as a size, so treat anything that is not a size as "unknown", not as 0x0.

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 size.

Command	What it does
wm density	Reports the display density, or overrides it — which is what actually moves a layout breakpoint.
screencap	Takes a screenshot, either to a file on the phone or to standard output as PNG.
getevent	Streams raw input events straight from the kernel, or lists what each input device can report.

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.