Choosing Devices for a Device Farm

Choosing devices for a device farm is a coverage-versus-cost optimization: buy the spread of models, OS versions, and hardware tiers that represents your real users, at battery and longevity quality that survives continuous duty. This page gives a framework and a concrete checklist.

Start from who you're representing

Before buying anything, define what "representative" means for your workload. A fleet for QA and compatibility testing needs to mirror the hardware and OS distribution of your app's actual install base. A fleet for market and localization research needs devices typical of specific regions, which can differ sharply from your home market.

Concretely, gather (or estimate) the distribution of:

• OS versions in active use — usually a long tail, not just the latest.
• Screen sizes and densities — layout bugs hide at the extremes.
• Hardware tiers — a lot of real users run mid/low-end devices that expose performance issues flagships never show.
• Regional model variants — the same model can ship different chipsets or bands per market.

Coverage that matches this distribution beats a pile of identical high-end phones every time.

New vs used vs refurbished

Screening used and refurbished units

Every non-new device should pass an intake check before joining the fleet:

• Battery health readout (design vs current capacity; iOS exposes this directly, Android via apps or dumpsys battery/OEM tools).
• No physical swelling — reject any bulging chassis or lifting screen outright.
• Charging behavior — does it reach and hold charge, and stay within normal temperature?
• Account/lock status — confirm it is clean, unlocked, and not activation-locked.
• Sensor/port function — USB data works reliably for ADB, screen and touch fully functional.

Building coverage: model and OS spread

The goal is maximum distinct coverage per dollar. Two levers:

OS-version spread

Keep a ladder of OS versions rather than clustering on the newest. Retain older-OS devices deliberately, because they're hard to recreate later — especially on iOS, where you can't downgrade freely (see iOS vs Android fleets). A device that's the only one still on an older major becomes disproportionately valuable.

Model and chipset spread

Different SoCs, GPUs, and RAM configurations surface different behavior. Prioritize:

• One or two anchors at the high tier (current flagships).
• The bulk in the mid tier, matching where most real users are.
• A meaningful low-tier presence to catch memory pressure and performance edge cases.
• OEM diversity on Android (different skins, defaults, and update behavior).

Avoid buying five near-identical units of one model unless you specifically need parallel capacity for that exact configuration.

Hardware tiers: RAM, CPU, storage

• RAM is the sharpest differentiator for app behavior. Low-RAM devices trigger aggressive process killing and out-of-memory paths that high-RAM devices never hit — valuable coverage.
• CPU/GPU tier affects timing, animation smoothness, and any performance-sensitive flow. Faster hardware can mask race conditions that slow devices expose.
• Storage matters for the fleet itself: automation artifacts, screen recordings, logs, and app data accumulate. Undersized storage causes install failures and flaky sessions. Favor devices with adequate free space, and monitor it (see fleet monitoring and health).

Battery health and longevity

Devices in a fleet run harder than consumer phones — often plugged in and active for long stretches. Battery and thermal characteristics decide their service life.

• Start from healthy batteries; a used device already at low capacity has little runway.
• Manage charge to extend life — duty cycling and charge limits, covered in USB hubs and charging at scale.
• Prefer devices with decent thermal design; phones that throttle or overheat under sustained load are unreliable fleet members.
• Track battery health over time and plan replacements before failures cascade.

Longevity also means spare-parts and stock availability: buying models you can re-source lets you replace failed units without breaking your coverage matrix.

None of this is a one-time purchase decision — sourcing, screening, and replacing devices is an ongoing procurement job for as long as the fleet runs, which is one reason some operators rent fleet capacity instead of building a device inventory themselves.

Budget tiers

Plan purchasing in tiers so growth is predictable:

Spend the largest share on the coverage tier, since that's where representativeness lives. Treat flagships as a small set of anchors and legacy devices as a preserved asset you protect rather than churn.

Purchase checklist

• Coverage matrix defined from real user distribution (OS, size, tier, region).
• Mix of new anchors + refurbished/used bulk chosen against budget tiers.
• Intake screening: battery health, no swelling, charging/thermal check, lock status, USB data.
• OEM and chipset diversity on Android; iOS generations spanning current + prior majors.
• Low-RAM devices included for memory-pressure coverage.
• Adequate storage headroom per device.
• Re-sourceable models chosen where possible for replacement continuity.
• Older-OS devices flagged and preserved.