how to set up ADB on cloudf.one and run any android automation script
if you want to run ADB on a cloud phone, the workflow is simpler than most teams expect. ADB has supported tcp transport for over a decade, and cloudf.one exposes that transport directly so any android automation script (appium, frida, uiautomator2, custom shell pipelines) runs against a real Singapore phone exactly as if the phone were sitting on your desk plugged into a usb cable. no emulator, no fingerprint problems, no carrier signal headaches.
this guide is the practical setup. install platform-tools, connect, mirror with scrcpy, layer on appium or frida if you need them, and lock down the security so you do not leave the phone exposed.
why ADB matters for cloud phones
a cloud Android phone without ADB is a fancy vnc session. with ADB, it becomes a programmable real device. you can install apps, push files, capture logs, run shell commands, mirror the screen, and drive ui automation frameworks that expect native android. for any team doing mobile app testing, multi-account social ops, or scripted device management, ADB is the difference between manual work and a real pipeline.
we covered the broader cloud phone case for testing in real device cloud phones for mobile app testing. this article picks up where that one ends, with the actual setup commands.
ADB on a real cloud phone also matters because emulator-based ADB is slowly dying. android attestation now flags emulators on more apps every quarter, and any framework that depends on the device passing safetynet (banking, tiktok, paid streaming, fintech) requires real hardware. once you have committed to a real device, ADB over the network from a cloud phone is the cleanest path to running any android automation script in production.
installing platform-tools on your laptop
ADB lives in google’s android platform-tools package. install once, use forever.
on macos: brew install android-platform-tools. on debian or ubuntu: apt install adb. on windows: download platform-tools from the official android developer site and add the folder to your path.
verify the install with adb version. you want at least version 34.0.0 for full tcp transport support and modern auth handling.
if you already have platform-tools from android studio, that copy works fine, no need to install again. just make sure which adb resolves to a single binary so you do not run an outdated version by accident.
connecting to your cloudf.one phone
each phone in your cloudf.one dashboard exposes an ADB endpoint and a short-lived auth token. the endpoint looks like adb.cloudf.one:5XXXX where the port is unique to that phone.
step one: from the cloudf.one web console, open the phone you want to drive. click the ADB tab. copy the endpoint and the auth token (the token rotates roughly every 24 hours, so do not bake it into a script that runs longer).
step two: from your laptop terminal, run adb connect adb.cloudf.one:5XXXX. the first time you connect, you will be prompted to authenticate. paste the auth token when asked.
step three: on the cloud phone (visible in the cloudf.one web view), an “allow usb debugging” dialog appears. tap allow, optionally check the “always allow from this computer” box.
step four: confirm with adb devices. you should see one entry like:
adb.cloudf.one:5XXXX device
if the entry is unauthorized, you missed the rsa fingerprint dialog on the phone. open the cloudf.one web console, accept the dialog, then re-run adb devices.
if the entry is offline, the auth token expired. fetch a new one from the dashboard and re-run adb connect.
once the phone shows as device, every adb command works.
scrcpy: the live mirror
ADB without a screen is fine for scripts but painful for development. scrcpy is the answer. it mirrors the phone in a window on your laptop, with mouse and keyboard input forwarded as native android events.
install with brew install scrcpy on macos, apt install scrcpy on debian, or download a windows build from the scrcpy github releases.
run scrcpy with the cloud phone connected via adb. a window opens with the live phone screen. mouse clicks become taps, keyboard input becomes android input, ctrl+shift+v pastes from your laptop clipboard into the phone.
for multi-phone setups: scrcpy -s adb.cloudf.one:5XXXX --window-title "phone-01" lets you target a specific device and label the window. open ten of them and arrange across your monitors.
scrcpy has zero dependency on cloudf.one’s web console. once your laptop has the adb connection, scrcpy works exactly as if the phone were on your desk over usb. latency is real (30 to 150ms typically) but rarely interferes with production work.
running appium against the cloud phone
appium is the most common android automation framework. it speaks ADB under the hood, so once your phone shows up in adb devices, appium just works.
install appium with npm install -g appium and the uiautomator2 driver with appium driver install uiautomator2.
start the appium server on your laptop: appium --base-path /wd/hub.
your test capabilities point at the network adb device:
{
"platformName": "Android",
"appium:automationName": "UiAutomator2",
"appium:udid": "adb.cloudf.one:5XXXX",
"appium:appPackage": "com.instagram.android",
"appium:appActivity": ".activity.MainTabActivity",
"appium:noReset": true
}
run your appium tests as normal. uiautomator2 will install its server apk on the cloud phone, drive the ui, and tear down. for python: pip install appium-python-client and use webdriver.Remote("http://localhost:4723/wd/hub", capabilities).
the same pattern works for any appium-driven framework: webdriverio, robot framework, or maestro.
frida basics for app instrumentation
frida is the heavier hammer. it injects a javascript runtime into a target process so you can hook methods, dump memory, and inspect runtime state. useful for app testing, security research, and reverse engineering.
frida needs a server binary running on the phone. download frida-server-X.X.X-android-arm64 from the frida releases page, then push and run:
adb push frida-server /data/local/tmp/
adb shell chmod 755 /data/local/tmp/frida-server
adb shell /data/local/tmp/frida-server &
note: many production cloud phones are not rooted by default. frida-server requires root for most useful hooks. cloudf.one offers rooted phones on request for testing accounts, but never use a rooted phone for social account ops, because Meta and TikTok detect su binaries and ban accounts within hours.
from your laptop, install frida tools: pip install frida-tools. then hook into a target with frida -U -n com.example.app -l hook.js. the -U flag tells frida to use the usb (or in our case, network adb) connection.
if you are doing app testing or reverse engineering, this is the entry point. if you are doing social account ops, you almost certainly do not need frida.
security notes you must follow
ADB is powerful, which means a leaked endpoint or auth token gives someone full control of your cloud phone. treat the auth token like a password.
never commit the adb endpoint and token to a public git repo. never paste them into a chat or screen share. rotate the token from the dashboard if you suspect leakage. revoke usb debugging from the phone settings if the phone is compromised.
cloudf.one’s adb endpoints are tls-wrapped and ip-filtered to your account, so an attacker cannot just connect from the internet. but if your laptop is compromised and your token is fresh, the attacker can drive the phone the same way you can.
for production scripts that run on a server (e.g. on .46 or your own vps), use the long-lived service token feature in the cloudf.one dashboard. these tokens are scoped to specific phones and revocable from the web ui, and they survive the 24-hour rotation that affects interactive tokens.
what you can build once ADB is wired up
once ADB and scrcpy work, the rest is just code. some patterns worth borrowing:
automated phone provisioning (install playbook, set device language, log in to apps) by piping shell commands into adb. mobile app regression testing across 10 to 50 phones in parallel using appium grid. multi-account social ops where each phone runs a low-rate script that mimics human input via input keyevent, with timing randomization. push notification testing across real carriers and IPs. payment integration testing with real telco billing.
if you arrived here because you are migrating from emulators, the emulator-to-cloud migration guide walks the broader workflow including app data export and account login transfers.
real phone, real adb, real automation. that is the entire setup.
FAQ
does ADB over network work the same as ADB over usb?
yes, every adb command is identical. the only practical difference is added latency (typically 30 to 150ms) which rarely affects scripts.
can I use scrcpy on a cloud phone the same way I would over usb?
yes. once adb connect succeeds, scrcpy treats the cloud phone as a normal local device. multi-window setups work too.
is the cloud phone rooted by default?
no. rooted phones are available on request for testing and reverse engineering, but never use root on social account phones because root detection is grounds for ban on most major apps.
will frida hooks survive a phone reboot?
no. frida-server has to be re-pushed and re-launched after every reboot. for persistent hooks, install the systemless frida module via magisk on a rooted phone.
is the ADB connection encrypted?
yes, cloudf.one wraps adb traffic in tls and restricts the endpoint to your account’s authorized ips. the auth token is single-account scoped.
can I run appium tests in parallel across many cloud phones?
yes. each phone has its own adb endpoint, so you can run multiple appium server instances or use appium grid to dispatch tests to many devices at once.