English
Русский
简体中文
繁體中文
Tiếng Việt
Bahasa Indonesia
Português
Español
An Android device farm is a set of test phones connected to host machines, so that automated tests and people can use them without picking them up. The term comes from QA, and that is how this article uses it: a shared pool of devices for running and reproducing tests. Racks of phones used to operate social accounts at scale are a different thing, break the terms of every major platform, and are not covered here.
Every mobile team reaches the point where a drawer of phones stops working. Someone took the Pixel home, nobody knows which phone has which build, and CI runs on a single emulator. This guide covers what a farm is for, what a self-built rack involves and costs, and when cloud phones do the same job.
What a device farm is for
- Automated UI tests on a matrix. Espresso, UI Automator or Appium suites on several Android versions and screen sizes at once, so a release candidate gets one clear answer.
- Reproducing a user's bug. The report names a model and an Android version, and the farm has that phone or something close to it.
- Manual and exploratory sessions. A tester opens a specific model remotely instead of borrowing it from a colleague.
- Long runs. Background sync, notification delivery and memory over hours, which an emulator thrown away after each CI job cannot show.
- Release smoke. The same quick pass on ten phones in parallel before a rollout.
Anatomy of a self-built rack
Building a rack is not hard. Keeping it healthy is the real work. A typical rack has five parts.
Phones. Pick them from your analytics, not from what is on sale: the top models by session share, the oldest Android version you support and the newest. Buy two of the most common model, so one can be in use while the other runs CI.
Power and USB. Powered hubs with enough current per port, short cables of decent quality, and a budget for USB host controllers. As a rule of thumb, adb gets unreliable somewhere past ten to fifteen phones on one host, depending on the controller and the hubs.
Hosts. Small Linux machines or Macs, each running the adb server for its shelf. Track devices by serial number and keep a map of which phone sits on which port, because you will need it at the worst moment.
Software. adb, a device manager such as DeviceFarmer (the community successor to OpenSTF) for remote screens and booking, Appium with a grid if you test through WebDriver, and your CI to schedule runs.
Housekeeping. This is the part nobody budgets for. Batteries swell when phones sit on a charger for months, so use the charge limit some vendors offer or smart plugs that cycle power. System update prompts appear in the middle of runs. Screens lock, notifications pile up, storage fills with test media, and a phone that crashed overnight boots into a dialog with nobody there to tap it.
What a rack really costs
For a rack of 20 phones, a rough 2026 estimate looks like this. Phones cost $3,000 to $12,000 depending on how many flagships you need. Hubs, cables, shelving and two hosts add $1,500 to $4,000. Then budget 20 to 30 % of the phone spend every year for swollen batteries, broken ports and the new models your users buy.
The line that surprises teams is time: three to eight hours a week of someone unsticking phones, applying updates and rebooting hosts. Your numbers will differ, but the shape will not. The hardware is the smaller part of the bill.
Cloud phones turn this into a running cost with no upkeep. On Clousd, pay as you go is $0.004 a minute while a phone runs and never more than $0.80 a phone a day, and plans start at $20 a month; the pricing page has the details. Two worked examples for the same 20 phones:
- Two hours each working day: 20 phones × 120 minutes × $0.004 = $9.60 a day, about $211 for 22 working days.
- Around the clock: the daily cap applies, so 20 × $0.80 × 30 days = $480 a month at most.
Pay-as-you-go minutes stop when a phone stops. A model you need for a single bug report is a phone you create, use and delete.
Own rack, device cloud or cloud phones
| Own rack | Public real-device cloud | Cloud phones | |
|---|---|---|---|
| Up-front cost | phones, hubs, hosts | none | none |
| Running cost | replacements and staff time | per session or per month | per minute while running, or a plan |
| Camera, GPU, battery | real | real | not representative |
| Vendor firmware and skin | yes | yes | depends on the provider |
| Phone available when you need it | if nobody else has it | shared, may be busy | created on demand |
| State between sessions | kept | usually wiped | kept until you reset it |
| Scaling for a release week | buy more phones | buy more time | create more phones |
| Upkeep | yours | none | none |
What a cloud setup changes
- Clean starts. A phone is created in about a minute and can be reset to a fresh state before each suite, so every run starts from the same place.
- Models as a parameter. Android 12 to 17 on 150+ real models, picked per run from the model list instead of from what is on the shelf.
- Remote by default. A live screen in the browser for manual sessions, a REST API and ADB for CI, and an MCP server when an AI agent runs the check.
- No hardware chores. Nothing swells, nothing needs a cable, nothing needs a reboot at 2 a.m.
What it does not change
Cloud phones are not physical phones. Camera pipelines, sensor accuracy, GPU performance, battery drain, thermal throttling, NFC, Bluetooth and vendor-specific background killers still need real hardware. Most teams end up with a hybrid: three to five physical phones on a desk for those checks, and the wide matrix of models and versions in the cloud. Testing an app on different Android versions lists what that matrix should cover.
Running tests on the farm, wherever it lives
Test runners address phones by their adb serial, so the same suite runs on a USB rack and on remote phones. AndroidJUnitRunner can split one suite across devices by shard:
R=com.example.app.test/androidx.test.runner.AndroidJUnitRunner adb -s "$P12" shell am instrument -w -e numShards 3 -e shardIndex 0 $R adb -s "$P14" shell am instrument -w -e numShards 3 -e shardIndex 1 $R adb -s "$P16" shell am instrument -w -e numShards 3 -e shardIndex 2 $R
Run the three lines in parallel and each phone takes a third of the tests. Appium picks a device through the appium:udid capability, which takes the same serial. Remote phones join the pool with adb connect; the ADB docs show how that works through a relay, and the app testing page shows the API route for CI.
Expect each remote action to take a little longer than over USB, and set your UI test timeouts with that in mind. Tests that pass on a local emulator and time out remotely usually have a hard-coded sleep or a wait that is too tight.
Mobile device farm and cloud phone farm
A mobile device farm is the same idea with iPhones and iPads on the shelf next to the Android phones. In QA, a cloud phone farm is simply the pool of cloud phones your suite runs on. The word "farm" has other meanings outside testing; the phone farm explainer covers them.
