← back to blog

using scrcpy to control your cloud Android phone like a local device

if you want scrcpy on your cloud phone to feel as fluid as a local USB-attached device, you have to set it up correctly the first time. most people get scrcpy connecting after a few tries, then live with sluggish input and weird clipboard quirks because nobody told them which flags actually matter on a remote ADB connection.

this guide walks the full setup. ADB tcpip, latency tuning, multi-device sessions, keyboard and clipboard sharing, automation hooks, and the small set of issues that come up regularly. for the recording side of scrcpy, see how to record screen on a cloud Android phone. for installing custom builds while you mirror, installing custom APKs on a cloud phone covers the install side.

if you have not used scrcpy before, the short version is that it is an open source tool from Genymobile that mirrors an Android device to your computer over ADB. it does not require root, it does not require an account, and it is faster than every commercial alternative I have tested.

connecting scrcpy to a cloud phone

a cloudf.one phone exposes ADB over the network. you do not have a USB cable. that is fine, scrcpy works over network ADB the same way it works over USB.

the first time you connect:

adb connect <device-ip>:<port>
adb devices
scrcpy

if the device shows up under adb devices as device and not unauthorized, scrcpy will launch and mirror the screen. if it shows offline, run adb disconnect and reconnect.

on cloudf.one we hand you the IP and port directly. you do not need to enable tcpip on the phone yourself. that means the workflow above is the whole setup.

latency on a remote ADB session

network ADB adds round-trip latency. local USB scrcpy feels instant. cloud phone scrcpy will feel about 30 to 80 ms slower depending on where you are in the world relative to Singapore. for human use this is unnoticeable for tapping and scrolling. for fast typing and rhythm games it is enough to matter.

three flags reduce the felt latency.

scrcpy --max-fps 60 --max-size 1280 --video-bit-rate 8M

--max-fps 60 lets scrcpy push 60fps when the network can support it. dropping to 30 only helps if your link is bad. --max-size 1280 is the secret weapon. it tells scrcpy to render at 1280 on the long edge instead of native 1080p or 1440p. fewer pixels, less encoding time on the phone, less decoding time on your laptop. the perceived input lag drops noticeably.

--video-bit-rate 8M keeps the stream high quality without ballooning the bandwidth. anything above 12M usually does not look better, it just consumes more network for no gain.

if your link is genuinely slow, drop bit rate first, max-size second, fps last. fps is what makes scrcpy feel responsive.

multi-device sessions

scrcpy supports multiple devices in parallel. each one gets its own window. on a wide monitor you can run six cloud phones at once and tab between them.

the simplest pattern:

adb connect <device1-ip>:<port>
adb connect <device2-ip>:<port>
scrcpy -s <device1-serial> &
scrcpy -s <device2-serial> &

each scrcpy process is independent. you can record one while controlling another. you can close one without disturbing the rest.

the serial is whatever appears in the adb devices output. for network ADB this is the ip:port string itself, so:

scrcpy -s 192.168.x.y:5555 &
scrcpy -s 192.168.x.z:5555 &

for high device counts past six or seven, your laptop becomes the bottleneck before the network does. video decoding adds up. either move to a workstation or run scrcpy with --no-display and just use the input passthrough.

keyboard and clipboard sharing

scrcpy forwards your physical keyboard to the phone by default. you type, it shows up in the focused field on the device. that part needs no setup.

clipboard is where most people get tripped up.

scrcpy supports clipboard sync in both directions. on Android 11 and newer the security model changed, so the clipboard only updates when an app explicitly receives focus. that means a copy on your laptop will not always paste cleanly on the phone the first time.

the reliable pattern:

• copy on your laptop
• click into the input field on the scrcpy window
• press ctrl-v on your laptop, which scrcpy translates to a paste

ctrl-shift-v sends the text as keystrokes instead of using the clipboard. that bypasses the Android 11 clipboard restrictions entirely. for filling in long passwords or pasting credentials into a flaky app, ctrl-shift-v is the workaround.

the reverse direction works too. text copied on the phone shows up in your laptop clipboard automatically. that one is rarely buggy.

automation hooks

scrcpy is also the easiest way to drive a phone from a script. anything you can do with adb shell input you can do while scrcpy is mirroring, and you get to see the result in real time.

a typical pattern:

adb -s <device-serial> shell input tap 540 1200
adb -s <device-serial> shell input text "hello"
adb -s <device-serial> shell input keyevent KEYCODE_ENTER

scrcpy itself does not interfere with these calls. you can write the script in python, bash, or whatever you prefer, and watch each step land on the mirrored screen. when something goes wrong you see exactly what the phone showed at the moment of failure.

for heavier automation, Appium plugs into the same ADB connection. scrcpy stays open as your visual debugger while Appium drives the actual test flow. that combination is what we use internally for any provisioning task on a real device.

troubleshooting

a few issues come up regularly enough to call out.

adb devices shows the phone as unauthorized. someone needs to accept the ADB authorization prompt on the device. on cloudf.one this is already handled, but if you reset the phone or rotate keys it can resurface. ask support to re-authorize the host, then reconnect.

scrcpy disconnects randomly during long sessions. usually a network blip. set --no-power-on and --turn-screen-off so the phone stops trying to wake your scrcpy session every time the screen state changes. if it persists, the underlying ADB tunnel may need a restart on the cloud side.

scrcpy launches but the window is empty or black. this usually means the phone is asleep with the screen off. send a keyevent to wake it: adb -s <serial> shell input keyevent KEYCODE_WAKEUP. then scrcpy will render normally.

input feels laggy on every command. drop --max-size to 1024 and confirm. if that fixes it, your laptop decoder was the bottleneck. if it does not, your network is the bottleneck and you need to test from a wired connection.

screen rotation does not follow the phone. scrcpy locks the rotation it saw when it started. close and relaunch scrcpy to pick up the new orientation. the --lock-video-orientation flag forces a specific rotation if you want to pin it.

the workflow that scales

after running scrcpy across hundreds of cloud phones, the workflow that holds up looks like this:

• one terminal window with all the adb connect commands as a script
• one launcher script that opens scrcpy on the devices you want, in the layout you want
• ctrl-shift-v as the default paste method, never trust silent clipboard sync
• scrcpy plus Appium for any task that benefits from automation

for a wider context on what running phones in parallel looks like across a team, the real device cloud phones for testing breakdown covers how the same setup powers QA fleets.

FAQ

does scrcpy work over the public internet on cloud phones

yes. cloudf.one routes ADB to the device over an authenticated tunnel. you treat it like a network ADB device and scrcpy connects normally. round-trip latency is the only meaningful difference from local USB.

can I use scrcpy on a Mac

yes. scrcpy runs on macOS, Linux, and Windows. the Mac install is brew install scrcpy. behavior is identical across platforms.

why is my scrcpy connection slow

usually one of three things. the phone is rendering at full native resolution, the bit rate is set too high, or your network has packet loss. lower --max-size first, then --video-bit-rate, then check the network.

can I run scrcpy headless

yes, with --no-display plus --record=output.mp4. scrcpy will encode the stream to a file without showing a window. useful for unattended capture or when you only want input passthrough.

does scrcpy require root

no. scrcpy works on stock Android with USB debugging enabled. cloud phones are stock and ADB is exposed by default, so you are ready out of the box.

how do I close scrcpy without losing my place on the phone

just close the window. the phone keeps running. scrcpy is just a viewer. closing the scrcpy window does not lock the phone, suspend the apps, or end any session running on the device.