ADB Input Commands: Automate Tap, Swipe, and Key Presses on Android

The adb shell input family of commands lets you simulate touch events, swipe gestures, typed text, and hardware key presses on a connected Android device without any app or root access. This is useful for automated testing, device provisioning, repeated UI interactions, and scripting workflows that you would otherwise perform by hand. The commands work the same way on Windows, macOS, and Linux as long as your ADB connection is active.

Finding the Right Screen Coordinates

All tap and swipe commands require pixel coordinates. Android measures from the top-left corner of the screen: X increases to the right, Y increases downward. A tap at the center of a 1080x2400 display would be at coordinates 540 and 1200. Two methods let you discover the coordinates you need without guessing.

The easiest method uses the Pointer Location overlay built into Android's Developer Options. Go to Settings → Developer Options → Pointer Location and toggle it on. A persistent overlay appears showing the real-time X and Y position of your finger. Touch the element you want to interact with and read the coordinate from the top of the screen. Write it down, then toggle Pointer Location off before running your ADB script, because the overlay itself consumes touch events and can shift coordinates slightly.

The second method uses getevent -l at the shell prompt:

adb shell getevent -l

This streams raw input events as you touch the screen. Look for ABS_MT_POSITION_X and ABS_MT_POSITION_Y values. These are in raw digitizer units that may need to be scaled to match your display resolution, which makes them less convenient than Pointer Location, but getevent is useful when the device does not have Developer Options accessible.

Simulating a Tap

A tap is the most basic interaction. The command takes X and Y as arguments:

adb shell input tap 540 1100

This sends a single finger-down and finger-up event at pixel 540, 1100. The duration mimics a normal tap rather than a long press. There is no feedback in the terminal; the event fires silently. If nothing happens, confirm you have the right coordinates by checking them with Pointer Location. Also verify that the screen is on and unlocked, because input tap does not wake the display.

For a long press, use input swipe with the same start and end coordinates and a long duration:

adb shell input swipe 540 1100 540 1100 1500

This holds a touch at the same position for 1500 milliseconds, which Android interprets as a long press.

Performing a Swipe Gesture

The swipe command takes starting X and Y, ending X and Y, and an optional duration in milliseconds:

adb shell input swipe X1 Y1 X2 Y2 DURATION

To scroll down a feed by swiping from the bottom to the top of the screen on a 1080x2400 device:

adb shell input swipe 540 1800 540 600 400

The 400-millisecond duration produces a moderately fast fling. Shorter durations make the swipe faster and throw the scroll further; longer durations produce a slow drag. For UI interactions that need to feel like a real user (to avoid triggering rate limits in apps), use durations between 300 and 800 milliseconds. To swipe horizontally through a carousel, keep Y constant and move X:

adb shell input swipe 900 1200 200 1200 350

Typing Text

The input text command types into whatever field currently has focus. Tap the input field first, wait a moment, then send the text:

adb shell input tap 540 900
adb shell input text "hello world"

Special characters require escaping. Spaces must be written as %s because the shell would otherwise split the argument. Ampersands, quotes, and parentheses also need escaping. The safest approach for complex strings is to use single-quoted shell arguments on Linux and macOS, or to escape each special character individually on Windows cmd:

adb shell input text "hello%sworld"

This types "hello world" with a space in the middle. Avoid sending Unicode characters beyond basic ASCII; the input text subsystem on many devices does not handle them reliably. For non-ASCII input, use a clipboard-based approach or a custom IME instead.

Sending Hardware Key Events

The input keyevent command fires a key code as if the user pressed a physical button. This works for navigation, volume, and power actions that have no visible tap target:

adb shell input keyevent 3

Useful key codes for common operations:

• 3 — HOME: returns to the launcher from any app
• 4 — BACK: equivalent to pressing the Back navigation button
• 24 — VOLUME_UP
• 25 — VOLUME_DOWN
• 26 — POWER: toggles the screen on or off
• 66 — ENTER: submits a form or confirms a selection
• 82 — MENU/UNLOCK: opens the lock screen or recent apps depending on context
• 187 — APP_SWITCH: opens the recents/overview screen
• 223 — SLEEP: immediately turns off the screen
• 224 — WAKEUP: turns the screen on without requiring a swipe

To wake the screen and go home before running a tap sequence:

adb shell input keyevent 224
adb shell input keyevent 3

Combining Commands Into Automation Scripts

On Linux and macOS, you can chain these into a shell script that runs a full interaction sequence. A simple example that opens the app drawer, waits for it to animate, and then types a search query:

#!/bin/bash
adb shell input keyevent 224       # wake screen
sleep 0.5
adb shell input keyevent 82        # unlock (swipe up on some launchers)
sleep 0.5
adb shell input tap 540 2200       # tap app drawer handle
sleep 0.8
adb shell input tap 540 300        # tap search box
sleep 0.4
adb shell input text "settings"
sleep 0.3
adb shell input keyevent 66        # press Enter

The sleep delays give the UI time to animate between steps. Skipping them causes commands to fire before the next screen is ready, producing missed taps. On Windows, use timeout /t 1 /nobreak in place of sleep for one-second waits, or use a PowerShell script with Start-Sleep -Milliseconds 500. Note that adb shell input cannot interact with secure text fields (such as password boxes), which reject synthetic input events for security reasons.