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.

input text

changes the device

Types a string into whatever field currently has focus.

Command: adb shell input text
Commands: Input and touch
Risk: changes the device

Syntax

input text <string>

Examples

```
input text 'hello world'
```
Quote it. Inside single quotes the shell leaves every character alone.
```
input text 'user@example.com'
```
Filling a login field from a real keyboard instead of a phone one.
```
input keyevent 66
```
Press Enter afterwards, since `input text` types no newline.

Reading the output

Nothing. The characters appear on the phone, or they do not — there is no report either way, so watch the screen.

Output fields

Field	Meaning
(no output)	The command ran. Whether the text arrived is only visible on the phone.

What access it needs

Nothing beyond an authorised `adb` connection — no root, no `adb root`, no `su`, and nothing to switch on in developer options besides USB debugging itself. `input` is a one-line shell script that runs `cmd input "$@"` (AOSP `cmds/input/input.sh`), so the characters are injected with the identity of the `shell` user, and the platform permission standing behind that is `android.permission.INJECT_EVENTS`, which `com.android.shell` is granted in its own manifest. What the grant deliberately does not include is any way to aim. `runText` accepts an input source, an optional `-d <displayId>` and the string, and nothing else — there is no argument naming a target app, activity or field — so the characters land wherever focus happens to be on that display at the instant they arrive. Pacing and ordering therefore matter far more in a script than access does: a dialog that appeared while you were not looking is a perfectly authorised place for your password to be typed. And there is no acknowledgement to wait on. `sendText` hands each event to the injector and never inspects a result, so the command exits without knowing whether anything downstream consumed a single keystroke; a `screencap` is the only honest confirmation.

Failure messages, decoded

Message	Meaning
java.lang.IllegalArgumentException: Argument expected after "text"	`runText` asks for a required argument and there was none, so `input text` with nothing after it throws. The line arrives under an `Exception occurred while executing 'text':` banner with a stack trace, all on stderr. Note what it is not: an empty string. `input text ''` is a legal, quoted, empty argument and does nothing quietly.
Exception occurred while executing 'text':	The shell-command handler caught a `Throwable`; the line after the banner names it. The non-ASCII case ends here: `KeyCharacterMap.getEvents` is documented to return null when the character array cannot be generated by the current key character map, and the source read for this page walks `events.length` with no null check, so a string containing `é` or `日本語` throws a `NullPointerException` rather than typing part of it. Older builds are reported to fail more quietly — see the note below — which is exactly why this page refuses non-ASCII up front instead of trying.
Error: Invalid arguments for display ID.	`-d` was given something that is not an integer and not `DEFAULT_DISPLAY` or `INVALID_DISPLAY`. It is thrown while parsing, before any character is sent, so nothing was typed. Look at the token after `-d`, not at your string.
cmd: Can't find service: input	`cmd` could not find the `input` service to hand the subcommand to, because `input.sh` is only a wrapper around `cmd input`. Expected while the device is still booting, before `system_server` has published it — the same shape of failure the `settings` and `window` services give at the same moment.

What it changes, and the way back

Nothing on the device is deleted, but the characters go to whatever has focus at that moment: a chat message, a search box, a login or password field, or a confirmation dialog that appeared since you last looked. Nothing takes them back once something submits them. If nothing has, `input keyevent 67` (Delete) removes them one character at a time, and it is `input keyevent 66` (Enter) that submits a form. Look at the screen before you type, and never send a secret you would not be willing to see left in that field.

Version and vendor notes

ASCII only, and this is a limit of the platform command rather than of the cable or the shell: `input text` ends in a virtual-keyboard character map that has keys only for printable ASCII, so Japanese, Chinese and accented letters produce no key events at all. A desktop adb cannot type them either.
`%s` inside the argument is turned into a space by `input` itself, before the keyboard ever sees it — and there is no escape for it, because `%%s` becomes a percent sign and a space. Split the string so that `%` and `s` are never adjacent in one invocation.
Single quotes cannot carry an apostrophe. Break the string there and send the apostrophe as `input keyevent 75`; the `'\''` escaping dance is the kind of thing that gets copied wrong.
A space needs no `%s` when the argument is quoted: the shell keeps it inside the one word and the keyboard maps it to the space key.

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 input text.

Command	What it does
input keyevent	Presses a hardware or virtual key — Home, Back, Power, volume, Enter.
getevent	Streams raw input events straight from the kernel, or lists what each input device can report.
am start	Starts an activity by component or by intent — the fastest way to test whether a deep link resolves.

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.