Emulators are polite. Real phones aren't.
Our Android device farm is a Raspberry Pi 4, a USB hub and four real Samsung phones, from a budget handset on Android 11 to a current one on Android 16. Our test suites drive them with Appium, Playwright or plain adb, as if they were plugged into the laptop running the tests.
Measured on 15–16 October 2026. Unlike the figures on our product case studies, these aren't read from a published build report: the farm runs on our office network and publishes nothing, so they carry the date they were taken instead.
How it fits together
Control and test traffic take different routes. That one decision is what makes the network tests possible.
Where the suite runs
One command opens a tunnel to the Pi. From then on, the phones appear to the test tools exactly as if they were plugged in locally.
Controls every phone over USB
It runs Appium and adb for all four phones at once, and keeps track of who has booked which one.
Reach the internet over Wi-Fi
No SIM cards. All test traffic goes over a dedicated test Wi-Fi network, which is where a bad connection can be simulated, one phone at a time.
Why real phones
Setting the farm up was its own argument for it. The phones arrived with Chrome and WebView as old as version 87, and one of them can't install a 64-bit app at all. That's what people actually carry around, and an emulator built from the latest image would show you neither.
Small screens, slow processors and old browser engines are where layouts break and timeouts fire. Those are the users who give up quietly rather than file a bug.
Why they're held still
A test result only means something if you know what it ran on. Two of the phones are pinned so they never take a system update, and none of them updates its browser automatically. Chrome and WebView move only on purpose, together with the driver on the Pi.
So when a suite that passed last week fails today, the phone isn't one of the suspects.
The phones
Chosen to spread across Android versions, screen sizes and hardware, not to be the newest.
Two more sit on the desk: a Pixel 9a on Android 17, the newest release, and an iPhone, both connected to a Mac rather than to the Pi. They aren't part of the farm, but they're booked through the same system, which keeps a farm suite and a desk test from clashing on one phone.
What makes a shared phone trustworthy
Driving a phone is the easy part. Most of the work went into making sure every run starts from the same place and leaves evidence behind.
One phone on 3G, the rest untouched
On a 3G profile, one phone's ping rose from about 20 ms to about 295 ms while the phone beside it stayed at 20. Taken fully offline, it lost every packet over Wi-Fi and still answered over USB, so the test kept control. The shaping clears itself when the booking ends.
Every run starts from the same place
A phone is booked before a run, and Appium, which runs sandboxed, refuses a session on a phone someone else has booked. A pre-run check confirms the phone is on the expected Android build and browser, awake, unlocked and charged, and fails loudly if not, so a suite can refuse to start. Two minutes after a booking ends, the phone resets itself to a clean baseline for the next one.
Recordings and logs from the run
A run can be screen-recorded end to end, for up to an hour, and the phone's system log captured from start to stop without clearing anyone else's. A failure comes with what the phone actually did, not just a stack trace.
Real sensors, controlled inputs
A test can put a QR code or a document on a display in front of the phones, so scanning flows go through a real camera rather than a stubbed one. It can also set a phone's location anywhere, for features that depend on where the user is.
Checked every morning
At 07:00 the farm checks the Pi and every phone against its inventory, so a phone that has wandered off its expected build is caught before anyone's suite trips over it. We tested the check too: fed five deliberately wrong expectations, it caught all five. The result shows on a live dashboard of every phone's state, battery and screen.
Watch a run as it happens
The dashboard can show a view-only picture of any farm phone's screen, refreshed every few seconds, while its tests run. When a suite stalls, you can see why without walking over to the desk.
What it doesn't do yet
The farm itself is Android only: iPhone testing happens on the desk device, outside it. It's reachable only from our office network. And there's one camera display, so scanning tests take turns.
Need it tested on the phones your users carry?
Tell us what you're shipping and we'll scope the device coverage that fits it.