A team planning a real-device evaluation often starts with a hardware question: how many Android devices should be in the pool? A useful estimate starts one step earlier. How many attempts must the workflow complete, how long does each attempt hold a device, and what share of the pool can actually serve that workload?
The answer is not a universal fleet size. It is a workload-specific estimate that can be checked against observed execution, queueing, and recovery data.
Start with attempts and device-occupancy time
For a first estimate, define the workload in attempts per hour and measure how long one attempt keeps a device unavailable for other work. Count the full reservation interval: preparation, interaction, evidence capture or transfer that holds the device, and cleanup or reset before release. Queue waiting before assignment is not device-occupancy time. If retries consume another reservation, count them in the attempt rate or explicitly in the expected work volume.
Little’s Law relates the average number of jobs in a stable system to the throughput rate and average time in the system. Applied to a device reservation boundary, it gives a simple starting point:
Average active device slots ≈ attempt rate per hour × average device-occupancy minutes ÷ 60
This is a planning relationship, not a prediction of the waiting time for any individual attempt. It assumes that the measured flow is stable over the window being analyzed and that the time and attempt rate refer to the same boundary. If you count only interaction time but the device remains reserved through reset and evidence handling, the estimate will be too low.
Convert average demand into a planning pool
Average active slots are not the same as the number of physical devices to provision. Some units may be unavailable, held for recovery, or incompatible with a task’s app, OS, account, network, or starting-state requirements. In addition, planning every eligible device at continuous utilization leaves no room for uneven arrivals, longer runs, or routine variation.
For a single workload cohort, use a transparent first-pass model:
Planning pool ≈ ceil((attempts per hour × average device-occupancy minutes) ÷ (60 × target utilization × eligible-and-ready share))
Here, target utilization is the average share of eligible device capacity you are willing to plan as occupied. The task-eligible and operational share is the observed fraction of the nominal pool that matches this workload’s configuration and is not out of service or held for recovery. Exclude ordinary in-use time from this share; target utilization accounts for planned occupancy. Estimate it from the same device cohort and operating conditions rather than treating fleet-wide online status as task eligibility.
These are planning inputs, not product constants. A lower utilization target or a smaller eligible share increases the estimated pool. Neither factor should be hidden inside an unexplained “safety multiplier.” If recovery time is already counted in the reservation interval, do not add it again as a separate per-attempt allowance. If unplanned downtime is reflected in the eligible-and-ready share, do not subtract it a second time.
A worked estimate
Suppose a benchmark workload is planned to submit about 12 device attempts per hour in a stable operating window. (If arrivals exceed completed attempts for a sustained period, the backlog is growing and the observed completion rate is not a suitable demand input.) A device is reserved for an average of 15 minutes per attempt: 4 minutes to prepare, 7 minutes to interact, 2 minutes for evidence handling while the device is still occupied, and 2 minutes to clean up and release it.
The average demand is:
12 × 15 ÷ 60 = 3 active device slots
Now suppose the planning target is 70% average utilization, and historical observations suggest that 80% of the nominal pool matches the workload and remains operational, excluding ordinary in-use time, during the relevant window:
ceil(3 ÷ (0.70 × 0.80)) = 6 devices
Six is a steady-load starting estimate under those assumptions. It is not a guarantee of a queue-wait target or of five devices being ready at every instant.
A separate peak constraint can change the answer. If five attempts may need to run at once, a simple point estimate using the same 80% task-eligible and operational share is:
ceil(5 ÷ 0.80) = 7 devices
The larger of the steady-load and peak estimates is therefore seven devices for this illustrative case. Because 80% is an average share, seven does not guarantee five eligible and operational units during every burst. If the peak is a hard requirement, use the observed distribution of ready eligible devices, define the confidence or percentile the operation requires, and validate it with a representative load test. If the work can wait in a queue, define how quickly the peak backlog must clear instead of treating every burst as simultaneous execution.
Check sensitivity before committing
Device occupancy is often the least certain input. Keep the other assumptions fixed and see how the answer moves if average occupancy changes:
| Average device occupancy | Average active slots at 12 attempts/hour | Steady-load estimate at 70% utilization and 80% eligible-ready |
|---|---|---|
| 10 minutes | 2 | 4 devices |
| 15 minutes | 3 | 6 devices |
| 20 minutes | 4 | 8 devices |
The estimate changes quickly because each extra minute consumes capacity across every attempt. Measure the reservation interval from assignment until the device is safely released, not only the time spent tapping through the app. Android’s managed-device testing guidance makes a related tradeoff explicit: sharding can shorten overall test time while consuming additional resources, and requesting more instances than can be provisioned can lead to timeouts. Firebase Test Lab also notes that shard startup overhead can increase device time. These are examples from managed test environments, not sizing guarantees for a physical Android fleet; they illustrate why parallelism and its setup cost must be measured together.
Size compatible cohorts, not an imaginary universal pool
A pool may contain multiple device profiles, but a task can use only the units that meet its requirements. Estimate separately where workloads require disjoint configurations—for example, a particular Android version, app build, account fixture, or network condition. Devices that can serve multiple cohorts may be shared, but the schedule must account for competing demand and reservations. Summing independent cohort estimates when the same devices can be reused may overstate the pool; applying one average eligibility percentage to incompatible workloads may understate it.
For mixed tasks, record the workload mix and occupancy by task class. A short task and a long stateful flow should not be treated as if they hold devices for the same interval. Likewise, expected retries belong in the demand model: a workflow completing ten user requests with retries may create more than ten device attempts.
Validate the estimate with a bounded run
Before buying or reserving a larger pool, run a representative workload and capture four things: arrival and burst patterns, reservation time from assignment through release, eligible-and-ready share by task cohort, and the queue and recovery behavior under load. Also watch for a different bottleneck: device control, task assignment, evidence transfer, storage, or evaluation may cap throughput before the devices do. That pipeline view extends the distinction between nominal device count and usable throughput discussed in Scaling Mobile AI Data Collection: From Device Count to Reliable Throughput.
Compare the estimate with observed completed attempts and queue delay. If results differ, find which input or stage changed before adding hardware. Re-estimate when the task mix, app setup, evidence policy, reset process, or target concurrency changes. For capacity planning, preserve the assumptions next to the estimate so another engineer can reproduce the reasoning.
A device-pool estimate is a model of a particular workload and operating window. Start with measured attempt demand and device reservation time, adjust for workload-specific readiness and a deliberate utilization target, then test the result under representative peaks. That produces a defensible planning range—not a device count detached from the work it must support.
Where ARMARRAY fits
When a workload requires physical Android execution, ARMARRAY provides the infrastructure layer. Teams can size and validate a pool around their own task mix, execution workflow, and evidence requirements, while keeping their task logic and evaluation systems in place.