scrcpy guide: control and record Android from your desktop

scrcpy puts an Android phone’s screen in a window on your computer and sends your keyboard and mouse back to it. On Android 11 and later it forwards audio too. It works over adb, so there’s nothing to install from the Play Store: each time it starts, it pushes a small server to the phone and runs it. The minimum is Android 5.0 (API 21).

The current release is 4.1, published in July 2026. Version 4.0, in May, moved the desktop client from SDL2 to SDL3 and added a few flags covered below.

I mostly use it for two jobs: watching an automation run live, and grabbing a screen recording of a bug with the exact taps that caused it. Everything here serves one of those.

What you need

• A phone with USB debugging on, showing up in adb devices.
• adb on your PATH. The WinGet package installs adb alongside scrcpy. With Chocolatey, Scoop or Homebrew you install it separately if you don’t already have it.
• Android 11 or later for audio, Android 12 or later for mirroring the camera instead of the screen.
• A USB cable that carries data. A charge-only cable is a classic reason a phone never appears.

Step by step

1. Install

On Windows:

winget install --exact Genymobile.scrcpy

Or scoop install scrcpy or choco install scrcpy, plus scoop install adb or choco install adb if needed. The release zip from GitHub works too. scrcpy is a command-line program, so run it from a terminal; the zip ships an open_a_terminal_here.bat for exactly that.

On macOS:

brew install scrcpy
brew install --cask android-platform-tools

On Linux, the scrcpy docs mark both the Debian/Ubuntu apt package and the Snap as obsolete versions. Arch’s pacman -S scrcpy is current. On Debian or Ubuntu I’d skip the distro package and use the project’s install_release.sh, which builds the latest release.

If it breaks: an old package won’t know newer flags and rejects them as unrecognized. Check scrcpy --version against the releases page.

2. First run

adb devices
scrcpy

A window opens with the phone’s screen in it. Clicks become taps and your keyboard types. Closing the window stops the server on the phone.

If it breaks: when the picture works but taps and typing do nothing, some phones need an extra developer option called “USB debugging (Security settings)”, which allows simulating input. Xiaomi phones are the usual case. The scrcpy FAQ says to reboot after enabling it.

3. Tune the video

Defaults are native resolution, 8 Mbps and H.264. That’s fine on USB. Over Wi-Fi, or with several phones on one machine, turn it down:

scrcpy --max-size=1024 --video-bit-rate=2M --max-fps=30

The short forms are -m 1024 and -b 2M. --video-codec=h265 gives better quality per bit where the phone’s encoder supports it, and 4.1 added VP8 and VP9 to the list alongside av1. H.264 stays the default because every phone has it.

If the stream fails to start on one particular phone, scrcpy --list-encoders shows the encoders it has and --video-encoder= picks one by name. A lower --max-size is worth trying as well, because some older encoders can’t cope with the panel’s native resolution.

Add --no-audio when you don’t need sound. That’s one less stream to fail.

4. Set up the phone side

scrcpy --stay-awake --turn-screen-off --show-touches

What each flag does:

• --stay-awake (-w) keeps the phone from sleeping, but only while it’s plugged in.
• --turn-screen-off (-S) switches off the physical display while mirroring carries on. MOD+o does the same at runtime and MOD+Shift+o turns the display back on. MOD is left Alt or left Super by default, and --shortcut-mod changes it.
• --show-touches (-t) draws touches on the phone. It only shows physical finger touches, not the ones scrcpy injects.
• --power-off-on-close turns the screen off when you quit.
• --no-control (-n) makes the window view-only.
• --keep-active, new in 4.0, stops the screen turning off by sending periodic activity.

For typing, the default --keyboard=sdk injects key events through Android’s API. --keyboard=uhid (or -K) makes the phone see a physical HID keyboard, which sorts out layout problems. The docs recommend it for regular use.

One more worth knowing about: --new-display=1920x1080 mirrors a fresh virtual display instead of the phone’s own screen, and --start-app= launches an app into it. The virtual display is destroyed when scrcpy exits.

5. Record

scrcpy --record=repro.mp4
scrcpy -r repro.mkv

The file extension picks the container. To record with no window at all, which is what you want on a build server:

scrcpy --no-playback --no-window --record=run.mkv
scrcpy --record=run.mkv --time-limit=120

I use .mkv for anything long. An MP4 gets its index written when recording stops cleanly, so a crash or a hard kill can leave a file most players won’t open. Matroska handles being cut off far better. Audio goes into the recording when the phone supports it; --no-audio gives you video only.

Recording over Wi-Fi is less fragile than it sounds. The recording docs note that timestamps are taken on the device, so network jitter doesn’t warp the file.

The built-in alternative is adb shell screenrecord /sdcard/demo.mp4. It needs nothing installed, but the adb docs list a 180-second maximum (3 minutes) and no audio.

6. Several phones at once

Run one scrcpy process per phone and point each one at a serial:

adb devices
scrcpy -s R58M12ABCDE --window-title='bench-01'
scrcpy -s 192.168.1.42:5555 --window-title='bench-02'

-d selects the only USB device and -e the only TCP/IP one, handy when you have one of each. Setting ANDROID_SERIAL works too.

Each window is its own video decode, so CPU and USB bandwidth add up quickly. On macOS or Linux, this starts a window for every attached phone at modest settings:

for s in $(adb devices | awk 'NR>1 && $2=="device" {print $1}'); do
  scrcpy -s "$s" --window-title="$s" -m 800 -b 2M --no-audio &
done

-m 800 -b 2M is just my starting point, not a measured optimum. Raise it until the machine complains.

7. Over the network

With the phone on your Wi-Fi, scrcpy can make the adb switch itself:

scrcpy --tcpip                 # phone on USB: finds its IP, enables TCP/IP, connects
scrcpy --tcpip=192.168.1.42    # phone already listening on port 5555
scrcpy --tcpip=+192.168.1.42   # force a reconnection

That’s the legacy adb tcpip mechanism underneath. On Android 11 and later you can pair with Wireless debugging instead and pass the resulting serial with -s. The ADB over Wi-Fi guide covers both, including why the connect port keeps changing.

For a phone plugged into a different machine, the scrcpy tunnel docs use SSH to reach that machine’s adb server:

# on the remote machine, where the phone is attached
adb start-server

# on your machine: forward local 5038 to remote 5037, and remote 27183 back to local
ssh -CN -L5038:localhost:5037 -R27183:localhost:27183 your_remote_computer

# in a second terminal on your machine
export ADB_SERVER_SOCKET=tcp:localhost:5038
scrcpy

The docs also show exposing the remote adb server on every interface with adb -a nodaemon server start, and warn that traffic between adb client and server is unencrypted. Use the SSH tunnel, and run the same Platform-Tools version on both machines.

Common pitfalls

• Mismatched adb binaries. If scrcpy and your other tools use different copies of adb, they kill each other’s server and every phone reconnects. Keep one Platform-Tools install first on PATH.
• Chasing quality over Wi-Fi. A full-resolution stream at 8 Mbps on a busy 2.4 GHz network stutters. Cut --max-size and bit rate before blaming scrcpy.
• Forgetting the window is live. Your mouse controls the phone by default, and one stray click can wreck an automation run. Use --no-control when you only want to watch.
• Expecting --stay-awake to work on battery. It only applies while the phone is plugged in.
• Treating scrcpy as an automation tool. It shows and controls a screen. It has no selectors, waits or assertions. For that you want a framework, and uiautomator2 vs Appium compares the two main ones.

Scaling this

With ten phones, the loop above and a window per phone is fine, if cluttered. Nobody watches fifty windows, though. At that size, record headless with --no-playback --no-window and open a live window only when a run fails. By then USB bandwidth, hub power and adb server stability matter more than any scrcpy flag, and the case for doing this on real hardware at all is in emulator vs real device testing.

This guide skips OTG mode, gamepads and V4L2 output. The scrcpy repository has a doc page for each, and they’re kept current with each release.

Written by Xavier Fok

disclosure: ADB Handbook is published by the team that runs cloudf.one. This article contains no sponsored links. Last reviewed by Xavier Fok on 2026-09-11.