ByteScope

input keyevent

changes the device

Presses a hardware or virtual key — Home, Back, Power, volume, Enter.

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

Syntax

input [-d <displayId>] keyevent [--longpress | --duration <ms>] [--doubletap] [--async] [--delay <ms>] <code or name> [<code or name> ...]

Flags and arguments

TokenMeaning
<code>The numeric key code. Names are also accepted on modern builds, but numbers work everywhere — and the difference is not cosmetic. `InputShellCommand.runKeyEvent` resolves the argument with `KeyEvent.keyCodeFromString` and sends whatever comes back without inspecting it, so a name this build does not know resolves to `KEYCODE_UNKNOWN` and is injected anyway: no error, no effect, exit status zero. The sibling `keycombination` subcommand does check the same value and throws `Unknown keycode:`; `keyevent` does not. A number cannot fail that way. More than one code may follow, and they are sent in order.

Examples

  • input keyevent 3

    Home.

  • input keyevent 4

    Back.

  • input keyevent 26

    Power — locks or wakes the screen.

  • input keyevent 187

    The recents / app-switch key.

Reading the output

Nothing. The phone reacts, or it does not; there is no confirmation either way. That silence is why this page spends its length on the failure table rather than on the output: the command exits zero after sending a key nothing was listening for, and it exits zero after sending `KEYCODE_UNKNOWN` because the name you typed was not one this build knows. The only honest confirmation is to look — take a `screencap`, or read back the state you were trying to change with `dumpsys`, `getprop` or `settings get` — and to treat the absence of an error message as no evidence at all. The timing switches are the one place `keyevent` will talk back: `--longpress` holds the key for the platform's own long-press timeout, `--duration <ms>` holds it for a stated time, `--doubletap` sends the same code twice with the platform's minimum double-tap gap between them, and `--delay <ms>` spaces out a list of codes given in one call.

Output fields

FieldMeaning
(no output)The key event was injected.

What access it needs

No root, and no `adb root`. `input` is a one-line shell script that runs `cmd input "$@"` (AOSP `cmds/input/input.sh`), so the event is injected with the identity of the `shell` user at the other end of an authorised `adb` connection. What that buys is deliberately narrow: `runKeyEvent` accepts a key code, the timing switches and an optional `-d <displayId>`, and nothing else — there is no argument naming a target app, so a key cannot be aimed at a chosen window. It goes to whatever holds focus on that display at the instant it lands, which makes the order and pacing of a script matter far more here than any permission does. Beyond USB debugging itself, nothing on this page is gated behind a developer-options toggle.

Failure messages, decoded

MessageMeaning
--duration and --longpress cannot be used at the same time.Both were passed. `runKeyEvent` prints this on stderr and then throws, so no key is sent at all. `--longpress` is a preset that sets the duration to the platform's long-press timeout, and stating a duration as well leaves the command holding two answers — drop one.
Error: Invalid arguments for command: keyeventA number was expected and something else arrived. `--delay` and `--duration` both parse their argument as a long, and `onCommand` turns the resulting `NumberFormatException` into this line with the subcommand name appended. Look at the value after the switch, not at the key code.
cmd: Can't find service: input`cmd` could not find the `input` service to hand the subcommand to. Expected while the device is still booting, before `system_server` has published it — the same shape of failure `pm` gives for the `package` service.

What it changes, and the way back

Individually harmless, but some codes have consequences: 26 is the power button, so it locks or wakes the screen, and a key sent into the wrong app is a tap you did not mean to make. Nothing here is destructive and nothing needs undoing.

Version and vendor notes

  • The codes used by this family, verified against the platform's own key-event definitions: 3 Home, 4 Back, 19 and 20 D-pad up and down, 24 and 25 volume up and down, 26 Power, 61 Tab, 66 Enter, 67 Delete, 75 apostrophe, 82 Menu, 187 app switch.
  • A key goes to whatever has focus. If a dialog appeared since you last looked, that is what receives it.

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

CommandWhat it does
input textTypes a string into whatever field currently has focus.
geteventStreams raw input events straight from the kernel, or lists what each input device can report.
screencapTakes a screenshot, either to a file on the phone or to standard output as PNG.

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.

Frequently asked questions

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

Would rather click than type? The Web ADB Toolkit runs commands like this from a browser over USB. Or browse every command.