ADB at scale: controlling many devices at once

Controlling one phone from a computer is a routine part of app development. Controlling a thousand phones from one computer is a different engineering problem, and it's the one that makes phone farms function as usable infrastructure rather than a room full of individually operated devices. The core tool underlying most of this on Android is the Android Debug Bridge, better known as ADB.

What ADB actually does

ADB is a command-line tool, included with the standard Android SDK, that lets a host computer communicate with a connected Android device over USB or a network connection. It can install and uninstall applications, push and pull files, issue simulated input events such as taps and swipes, capture screenshots, and stream device logs back to the host. Every one of these operations targets a single device per invocation — ADB's basic unit of control is one device, identified by a serial number or network address.

From one device to many

Because ADB addresses devices individually, controlling a fleet means running many ADB sessions in parallel rather than inventing a new protocol. Orchestration software sits on top of ADB (or an equivalent vendor automation API for non-Android platforms) and handles the parts ADB does not: maintaining a list of connected devices, queuing tasks, distributing them across whichever devices are currently available, retrying failures, and aggregating results into a single report. This layering — a simple per-device control primitive plus a scheduling layer above it — is the same basic pattern described in how phone farms work.

Addressing and selecting devices

At fleet scale, a task rarely needs to run on literally every device without distinction. Orchestration layers typically support selecting devices by attribute — OS version, model, region, or current health status — so a QA suite can target only devices running a specific Android version, or a monitoring job can run only against devices in a particular geographic pool. This selective addressing is part of what separates basic scripted ADB usage from genuine fleet orchestration.

Parallelism and its limits

Running commands across many devices at once is not infinitely parallel in practice. Host machines have finite USB or network bandwidth, and a single ADB server process handling too many concurrent device connections can become a bottleneck itself. Larger fleets commonly split devices across multiple host machines, each running its own ADB server and a subset of the fleet, with orchestration software coordinating across hosts rather than assuming a single computer can address every device directly.

Reliability at scale

Individual devices disconnect, become unresponsive, or return errors regularly enough that fleet automation has to expect and handle it rather than treat it as exceptional. Robust orchestration retries failed commands, flags persistently unresponsive devices for a health check, and continues operating the rest of the fleet rather than stalling on one bad device. This connects directly to the device lifecycle work covered in device lifecycle — a device that fails ADB commands repeatedly is often a candidate for maintenance or replacement, not just a transient glitch to retry indefinitely.

Where this fits in fleet use cases

ADB-driven automation underlies most of the common use cases for phone farms — QA testing installs builds and reads back results through it, monitoring jobs script repeated interactions through it, and any workflow that needs to drive real Android hardware programmatically ultimately routes through the same basic control primitive. The same coordination challenge applies whether the fleet runs physical devices or emulated ones, a distinction covered in emulators vs. real devices — ADB addresses both identically, since to the protocol an emulator and a real device look much the same.

Beyond Android

Fleets that include iOS hardware rely on a different stack rather than ADB itself, since ADB has no iOS counterpart. On-device UI control comes from XCUITest, driven through a WebDriverAgent instance running on the phone; host-side device management (installing apps, reading device state, managing provisioning) commonly goes through libimobiledevice or go-ios. All of it requires a macOS host — there's no way to run the iOS equivalent of an ADB server on Linux or Windows.

The shape of the problem is the same as on Android: a per-device control primitive, with orchestration layered on top to queue tasks, distribute them across available devices, and handle failures gracefully. What differs is depth and openness — ADB is a single, well-documented tool that does most of what fleet control needs out of the box; the iOS stack is several tools bridging Apple's more locked-down platform, and it demands the macOS-host layer that Android doesn't. See iOS vs Android fleets for a fuller comparison of the two automation stacks and what they cost to run.