ScrcpyForAndroid: running an scrcpy session from the phone itself

The scrcpy host moved onto Android

scrcpy is normally a program you run on a computer to mirror and control an Android device. ScrcpyForAndroid inverts that: it is an Android application that acts as the client, so the session lives on another Android device rather than on a desktop.

The project describes itself plainly as an scrcpy android client, and it states clearly that it is not the official version and has no affiliation with the original author or maintainers. It mirrors the video and audio of an Android device connected through ADB Wireless and allows control with a touchscreen and with a keyboard and mouse.

Two constraints shape the whole design. No root permission is required, and nothing is installed on the controlled device. The second point is what makes the project possible as an app: the controlling side talks to the standard scrcpy server running on the target, so the target needs no side-loaded application and no system modification.

The codebase is Kotlin, with a Gradle build, an app/ module, a submodule/ directory for the native components, a doc/ directory and a TODO.md alongside the CHANGELOG.md. The licence is Apache License 2.0.

This is a personal project with a clear point of view. It is built for the case where a laptop is not the machine you have in your hand.

Pairing over wireless debugging with mDNS and QR codes

Connecting is where the app departs most from the desktop workflow, because a phone has no USB port to hand you an authorisation prompt.

The project uses mDNS services to implement automatic connection to devices with wireless debugging enabled, and to automatically discover the IP address and port of devices that are waiting to be paired. QR code pairing is supported as well, and the code generator credited in the credits section is nayuki's QR-Code-generator.

The features list also covers multiple configuration switching, with configurations that can be bound to a specific device, and a full screen entry as soon as the connection is made. That binding is what makes the app usable as a daily tool: a configuration per phone means the codec settings, bitrate and virtual button layout follow the device rather than being set by hand each time.

Automatic rotation between portrait and horizontal orientation is handled, and there is a dedicated wide layout, though it applies only to devices whose screen aspect ratio is smaller than 16:9. In full screen, the back key can be mapped to the remote device, which is the kind of small mapping that makes a mirrored session tolerable when the controlling device has no physical keyboard.

One operational detail from the FAQ is worth knowing before you blame the app: when the app is pushed to the background, ADB can disconnect, and the fix is to set the power saving strategy of domestic ROMs to unrestricted and enable background use with the unrestricted setting in the native Android settings.

Control features: local keyboard input, clipboard sync, virtual buttons

The control story is where most of the engineering went.

The local input method can be raised while controlling, and Chinese input is supported, which matters because typing on a phone keyboard is otherwise painful. Clipboard synchronisation is included, and so is automatic filling of the lock screen password with biometric authentication, with the entry point placed among the virtual buttons.

There is also a virtual button system that can be reordered, a multi touch test screen, gamepad support, and a picture-in-picture mode. A streaming adb terminal and bidirectional file transfer are included as well, and recording is built in.

Audio is the part with the caveat. A low latency audio path exists but is disabled by default. When the controlled device plays a USAGE_MEDIA stream, the project reports that the audio delay between the two devices differs by only half a beat, and it notes there is no specific measurement capability behind that claim. When the controlled device plays a USAGE_GAME stream, a perceptible delay of 100 to 200 milliseconds remains.

Two details from the FAQ explain behaviour that otherwise looks like a bug. The virtual screenshot button works by sending keycode 120, which Android defines as the System Request or Print Screen key, and vendors implement it differently, on some AOSP-like systems such as AxionOS producing a soft reboot. And the bitrate slider tops out at 40Mbps, but every slider label can be tapped to type in your own value.

Picture in picture that keeps streaming after you close it

Picture-in-picture is implemented with reference to the moonlight-android project, and the PiP behaviour is listed among the features alongside a gaming layout. But the known issues section contains the line that matters most for anyone planning to use it daily: closing picture-in-picture does not stop the scrcpy stream, and you still have to go back into the app and stop it yourself.

That is a real resource decision rather than a rounding error. The stream continues to consume the encoder and the network, so a user who pins the session into a small window and swipes the app away leaves a live connection running until they notice.

The same known issues section is candid about another limitation: the application may fail to run properly on lower Android versions, and the picture-in-picture feature in particular depends heavily on how domestic ROMs implement it. The project explains that there were no devices available to test with, and being explicit about the limits of testing rather than claiming broad compatibility.

The NOT-TODO section sets out the same boundary from the other direction. Low version Android adaptation is explicitly out of scope, with the note that the project's minSdk is 26, corresponding to Android 8, and that 98.4 percent of devices can install it successfully, so problems, especially crashes, are expected to be reported with logcat rather than treated as a compatibility promise. Further recording optimisation is also declined, because MediaCodec imposes too many limits and continuing would require introducing ffmpeg.

Building the app from source with JDK 21 and NDK 30

The build is documented, and the requirements are specific. You need JDK 21, the Android SDK with compileSdk 37 and buildTools 37.0.0, and the Android NDK at version 30.0.16248370, which has to match the libcxx version in use. The NDK requirement is not optional detail: the native side of the project borrows JNI ADB work from rikkaapps/shizuku, borrows ssl bits from vvb2060's ndk.boringssl and uses lsposed libcxx, so the native toolchain has to line up.

The clone has to bring submodules with it:

git clone --recursive https://github.com/Miuzarte/ScrcpyForAndroid.git
cd ScrcpyForAndroid
./gradlew assembleDebug

If the repository was already cloned without them, the fix is one command:

git submodule update --init --recursive

And to build a single ABI for a release:

./gradlew assembleRelease -PabiList=arm64-v8a

The interface is built with the miuix Compose components, the settings page navigation follows the pattern of the WOMMO app, and the terminal implementation is taken from the termux-kotlin-app project, with only the Apache 2.0 portion used. The scrcpy server that is pushed to the controlled device can be replaced, which is the hook for anyone who needs a different server build than the bundled one.

The known issues list is more useful than the feature list

Most open source READMEs list features. This one also lists what is broken, and that section is where a reader should start.

At the start of a stream there is a probability of losing a keyframe, which shows as a garbled picture until the next keyframe arrives. Switching the interface language requires restarting the app before full screen works again. Inputting Chinese text across devices is implemented through clipboard synchronisation, which fills the controlled device's clipboard history with your typing history, and the project admits it does not know why it sometimes fails to reach the screen.

The feature list is not padded either. The scrcpy server is replaceable, mDNS handles discovery of both connectable and pairing-waiting devices, and there is automatic rotation. The FAQ additionally notes that recorded and downloaded files are written to /sdcard/Movies/Scrcpy/ and /sdcard/Download/Scrcpy/, and that MIUI virtual displays can show no desktop or a white screen, with the suggested fix being a third party launcher.

Two companion modules are recommended for cases the app cannot handle. The DisableFlagSecure module from LSPosed is suggested for password lock screens that cannot be captured, and a gist is linked for enabling ADB automatically at boot. Both are workarounds for Android restrictions rather than features of this project, and both add a dependency on other people's tooling to your setup.

Apache-2.0 and a release line that moves every week

The licence is Apache License 2.0, with the LICENSE file at the repository root. That is a permissive licence with an explicit patent grant, so embedding or redistributing the app carries no commercial condition.

Maintenance is brisk. The repository is not archived, the last push was on 2026-10-14, and the release history shows v0.6.8 on 2026-09-29, v0.7.0 on 2026-10-05 and v0.7.1 on 2026-10-14. Releases are published from the releases page on GitHub as installable packages.

A weekly cadence has two consequences. First, the changelog moves faster than most users read, and the project keeps its own TODO.md and CHANGELOG.md in the repository for that reason. Second, the version number is still in the 0.x range, so the usual semver stability promise does not apply and a minor bump can change behaviour.

For an evaluator the sensible order is: read the known issues, decide whether picture-in-picture streaming that you must stop by hand is acceptable, check that your target devices are on Android 8 or later, and read CHANGELOG.md before upgrading an existing installation. For anyone who wants to build rather than install, the NDK and libcxx alignment is the step that most often blocks a first successful build.

Editorial conclusion

Adopt ScrcpyForAndroid if you need to control one Android device from another Android device over ADB wireless and accept the rough edges the project documents, in particular the picture-in-picture stream that keeps running after the window closes and the clipboard based route for non-Latin text input. Do not adopt it as a replacement for the desktop scrcpy client, which remains the better choice when a laptop is available, and do not expect support for Android versions below 8. Before you install, check that wireless debugging is enabled on the target device, read the FAQ entries about background ADB disconnects and MIUI virtual displays, and read the CHANGELOG.md before upgrading, because the project ships releases weekly and behaviour does change between them.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Miuzarte/ScrcpyForAndroid on GitHub
4. README
5. Releases