input keyevent
changes the devicePresses 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
| Token | Meaning |
|---|---|
| <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 3Home.
input keyevent 4Back.
input keyevent 26Power — locks or wakes the screen.
input keyevent 187The 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
| Field | Meaning |
|---|---|
| (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
| Message | Meaning |
|---|---|
| --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: keyevent | A 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.
Related commands
Commands that turn up in the same session as input keyevent.
| Command | What it does |
|---|---|
| input text | Types a string into whatever field currently has focus. |
| getevent | Streams raw input events straight from the kernel, or lists what each input device can report. |
| screencap | Takes 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.