scrcpy: mirror and control an Android device without installing anything on the phone

The problem scrcpy solves: a real phone on your desk, without a client app

Most screen-sharing tools for Android assume you will install something. A remote support app, an MDM agent, a test harness, a vendor client. scrcpy takes the opposite route. It talks to the device over ADB, which is already part of the Android developer workflow, and it renders the device screen in a window on the computer. The README states plainly that it requires no root access and no app installed on the device, and that nothing is left installed on the Android device afterwards. That last point is the one that matters operationally: you can hand the phone back unchanged.

The intended audience is developers and testers rather than end users. Someone debugging a layout on a physical handset, someone recording a bug reproduction, someone demonstrating an app on a projector, someone driving a phone whose screen is cracked. The README lists lightness, performance, quality and low latency as the design focus, and quotes 30 to 120fps depending on the device, 1920x1080 or above, 35 to 70ms latency and roughly one second to the first image. Those are the project's own stated targets, not independent measurements.

The device side is the constraint. The README requires at least API 21 (Android 5.0), and audio forwarding only from API 30 (Android 11). USB debugging must be enabled. So the tool is for people who control the device and can turn on developer options, not for reaching a stranger's phone.

How scrcpy works: an ADB server process, a video stream, and injected input

The repository layout tells you most of the architecture. There is an app/ directory, which is the desktop client; a server/ directory, which is a Java component pushed to the device; and a meson.build at the root, which builds the native client. The client is written in C. The server is not a persistent app: it is a small program scrcpy pushes over ADB and runs on the device for the duration of the session.

Once running, the server captures the device screen through Android's own capture APIs, encodes it, and sends the stream back over the ADB channel. The client decodes it and draws it in a window. Input travels the other way: keystrokes and mouse events from your computer are converted into Android input events and injected on the device. This is why the README warns about a specific failure on some devices, especially Xiaomi, where you get "Injecting input events requires the caller (or the source of the instrumentation, if any) to have the INJECT_EVENTS permission." The fix it gives is to enable an additional option, USB debugging (Security Settings), which is a different item from USB debugging, and to reboot the device once it is set.

There is a second input path that bypasses Android's input system entirely. The README describes physical keyboard and mouse simulation (HID) and a gamepad option, where the computer presents itself to the device as a USB peripheral. In OTG mode, scrcpy controls the device without mirroring, and the README notes USB debugging is not required for that mode. That distinction is worth holding onto: normal mirroring needs ADB, HID-style control does not.

Installing scrcpy and mirroring a phone for the first time

The README does not put install commands in the main file. It points to per-platform pages: doc/linux.md, doc/windows.md and doc/macos.md, and for Windows it adds a link to how to run the tool. So the honest first step is to read the page for your system rather than copy a command from a blog. Package availability differs by distribution and by whether the packaged version matches the current release, v4.1.

What the README does give directly is the device-side prerequisite. On the phone, enable USB debugging, which the README links to the Android developer documentation. Then connect the device over USB and check that ADB sees it:

adb devices

You should see one line with the device serial and the state `device`. If the state is `unauthorized`, accept the debugging prompt on the phone screen. Once that works, the default session is a single command with no arguments:

scrcpy

A window should appear showing the device screen, and your keyboard and mouse should drive the phone. The README says the first image takes about a second, which is its stated figure.

From there the useful flags are documented in separate pages. The README's own examples include reducing the resolution when performance is poor, and switching codecs:

scrcpy --video-codec=h265 --max-size=1920 --max-fps=60 --no-audio --keyboard=uhid
scrcpy --video-codec=h265 -m1920 --max-fps=60 --no-audio -K  # short version

The first line captures in H.265, caps the size at 1920, caps the frame rate at 60fps, disables audio, and simulates a physical keyboard. The second line is the same set of options using short forms, and the README presents them as equivalent. Note that `-m1024` appears in the tips section as the recommended lever for performance on a weak device or a weak link.

Wireless mirroring, virtual displays and what each one costs you

scrcpy runs over TCP/IP as well as USB, documented in doc/connection.md under the TCP/IP wireless section. The trade-off is the usual one for wireless ADB: you gain freedom of movement and lose stability, and the README's latency figures are quoted for the tool in general rather than broken out per transport. If you are chasing the 35 to 70ms figure, USB is the safer assumption.

Virtual display is the more interesting feature and the one most likely to be misunderstood. The README shows starting VLC in a new virtual display, separate from the device display:

scrcpy --new-display=1920x1080 --start-app=org.videolan.vlc

This does not mirror what is on the phone. It creates a second, independent display on the device and launches an app into it. A variant with `--new-display -x` uses a flex display, and `--keep-active` keeps the display from turning off. For anyone who wants to run an app on a phone without disturbing whatever the phone is currently showing, this is the mechanism. It is also a case where the Android version and the device's support for multiple displays matter, and the README does not promise a minimum API for virtual display the way it does for audio.

Two other features sit outside the mirroring path. Camera mirroring works from Android 12, and can record straight to a file:

scrcpy --video-source=camera --video-codec=h265 --camera-size=1920x1080 --record=file.mp4

On Linux only, the same camera stream can be exposed as a V4L2 webcam with `--v4l2-sink=/dev/video2 --no-playback`, which lets other applications treat the phone as a camera. That is a genuinely different use of the tool from screen mirroring, and it is constrained to one platform.

Where scrcpy is the wrong tool

The most common misconception is that scrcpy is an Android emulator. It is not. There is no virtual Android system in the repository; the app/ directory is the desktop client and the server/ directory is the on-device component. If you do not have a physical Android device, scrcpy has nothing to display.

Second, it is not an iOS tool. The README describes Android devices connected via USB or TCP/IP. Nothing in the repository layout suggests an Apple device path, and the related searches for scrcpy on iOS have no counterpart in the documentation.

Third, the dependency on developer settings is a real boundary. USB debugging is a developer option, and on some devices a second security-related debugging toggle is needed before input injection works at all. In managed or locked-down fleets, turning those on may be exactly what policy forbids. OTG mode is the exception here, since the README states USB debugging is not required for it, but OTG mode also does not mirror the screen, so it does not solve the display problem.

Fourth, the tool is a command-line application with a large option surface spread across separate documentation pages. The README lists sixteen documentation pages under user documentation, from connection to shortcuts. There is no built-in settings window described in the README, and the related searches for a scrcpy GUI are not answered by anything in the documentation. If your team needs a point-and-click interface, plan for the extra work of wrapping the CLI or look elsewhere.

Finally, audio has a hard floor. Audio forwarding is Android 11 and above. On Android 10 or older you get video and control, and `--no-audio` in the README examples is not only a performance flag but the only option available on those devices.

scrcpy against Android Studio's device mirroring and Vysor

The closest thing most Android developers already have is the device mirroring built into Android Studio, which shows a connected device inside the IDE. The difference in approach is where the work happens. Android Studio integrates the mirror into a development environment, alongside logcat, the debugger and the layout inspector, and it expects you to be working in that environment. scrcpy is a standalone native client that starts in about a second according to the README and does not require the IDE to be open, or installed. If your task is to hand a phone to a colleague in another room and let them drive it, scrcpy is the smaller dependency.

Vysor is the other name that comes up. It is a commercial product with a free tier, and it targets a similar job with a browser-based or desktop client, which makes it easier for non-developers. scrcpy's position is the opposite: no account, no ads, no internet required, per the README's list of user benefits, and Apache-2.0 licensed. The cost of that position is the command line and the requirement that the person driving the device understands ADB well enough to get past `adb devices`.

A third comparison worth making is against ADB's own `screenrecord` and `screencap`. Those give you a file, not a live session, and they do not carry input back. scrcpy's contribution is the bidirectional channel plus the low-latency decode path, and that is the thing you would have to build yourself otherwise.

Licence, maintenance and what an upgrade actually involves

scrcpy is licensed under Apache-2.0. That is a permissive licence, which means redistributing it inside a commercial product is generally permitted provided you meet the licence's notice and attribution conditions. I am not a lawyer and this is not legal advice; if you plan to ship scrcpy or a modified client, have someone read the LICENSE file at the repository root and the Apache-2.0 terms properly. One practical point the README makes is about provenance: the GitHub repository is stated to be the only official source, and it warns against downloading releases from other websites even when the name contains scrcpy. Combined with the release signature verification page in the documentation, that is the supply-chain story you should follow.

On maintenance, the last push to the default branch was on 2026-07-12, the same date as the v4.1 release. The prior releases were v4.0 on 2026-05-12 and v3.3.4 on 2025-12-17. The repository is not archived. The release cadence visible in those three tags is uneven: a large gap between the December 2025 patch and the May 2026 major, then a two-month gap to v4.1.

The upgrade cost is not trivial in the way a library bump is, because scrcpy ships a client and a server that must match. The server component lives in server/ and is pushed to the device by the client at session start, so upgrading the client on your computer also changes what runs on the phone. That is convenient, since you do not manage the device side by hand, but it means a client upgrade can change on-device behaviour without anything being installed permanently. If you have scripted around specific flags, check the documentation pages for your options after moving to v4.1, and verify the release signature using the procedure in doc/verify-release.md rather than trusting a mirror.

Editorial conclusion

Adopt scrcpy if you need a low-latency view of a real Android device for QA, demos, remote support or screen recording, and you can accept that the device must run Android 5.0 or newer with USB debugging enabled. Do not adopt it if you need an emulator, iOS support, or a managed GUI product; scrcpy is a command-line tool that displays a device you already own. Before rolling it out, verify three things on your own hardware: that your distribution or the release archive gives you a build matching v4.1, that your device accepts input injection (Xiaomi devices may need the separate USB debugging (Security Settings) option plus a reboot), and that your audio use case runs on Android 11 or newer, since audio forwarding is not available below API 30.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes