A mobile AI team may need a broad compatibility sweep, recurring regression runs, and a private evaluation of an unreleased product. Those are different workloads and do not have to use the same device pool.
Some projects require all work and related data to remain within a defined private boundary from the outset. When that is a hard requirement, it constrains every option; otherwise, privacy controls are one factor alongside capacity, coverage, and cost.
Public catalogs and dedicated fleets can complement each other: use each for the workloads it fits, while keeping environment and evidence context attached to results.
Check privacy requirements, then compare capacity
If a project has a strict privacy requirement, map its complete data path: task instructions, prompts, app and account state, commands, screenshots, logs, evaluation outputs, support access, storage, and retention. Identify what must stay within the approved boundary and verify the actual deployment and service controls against it. NIST’s Zero Trust guidance focuses on protecting resources through explicit access decisions rather than trusting network location alone.
This is particularly relevant when a team tests a commercialization path, unreleased product behavior, or other work that must remain confidential throughout. A dedicated label alone does not prove that a deployment meets the requirement, and a public label alone does not determine whether its controls are sufficient; assess the actual data flow, access, support, and retention terms.
Match the access model to the workload shape
After checking any hard privacy constraints, estimate how much device capacity the workload needs and for how long. A small number of devices used for a short, one-off sweep will often be simpler through a managed public service: the team can access a supported catalog without purchasing, preparing, and maintaining a fleet that will soon sit idle.
The calculation changes when work repeats or peaks at higher concurrency. A recurring evaluation suite, continuous data collection, or a fixed daily window may benefit from reserved devices or a dedicated cohort. The relevant inputs are not just total device count, but peak simultaneous runs, hours or days of use, burst patterns, queue tolerance, setup and reset time, and the cost of unused capacity between runs. There is no universal duration or concurrency threshold; compare the expected task schedule with the service’s actual quotas, availability, and reservation model.
Device coverage is also a workload question. A public catalog can make it convenient to sample a wide or changing set of models. A dedicated fleet offers a known cohort for repeated comparisons, but it may not cover every model in a broad compatibility matrix. If a project needs both breadth and a stable baseline, use the public catalog for less common devices and the dedicated cohort for recurring controlled runs, provided each workload’s data path is acceptable.
Compare the full cost of an evidence-complete run
Compare the cost of a usable result over the same time window and task mix—not only the hourly service rate or hardware purchase price. Include reserved or consumed device time, setup and reset work, integration, operations, connectivity, storage, retries, and the cost of idle capacity. Then divide by the number of attempts that finish with evidence sufficient to interpret the outcome.
A public service can reduce procurement and maintenance work, especially for short or intermittent use. A dedicated fleet can make recurring capacity and configuration more predictable, while adding responsibility for preparation, replacement, monitoring, and recovery unless those are provided as part of the deployment. Provider-managed dedicated arrangements can shift some operations without changing the need to verify the project’s data boundary.
The comparison should use observed or estimated workload inputs. Do not assume that a dedicated fleet is always cheaper at scale or that a public catalog is always cheaper for short use; utilization, queueing, setup overhead, service terms, and evidence requirements can change the result.
Keep context attached to every result
A result is only comparable when its execution context is visible. Record the device model and identifier, Android build, app version, account or fixture state, network conditions, task version, reset procedure, attempt identifier, and evidence references. Keep the origin pool and relevant service configuration with the result as well.
This allows teams to distinguish a change in agent behavior from a change in device or environment. It also prevents a hybrid evaluation from blending runs across unlike conditions into one unexplained score. Public and dedicated results can be brought into a shared analysis pipeline only through an explicit integration. Otherwise, keep them in their respective systems. In either case, compare results only where the task, configuration, and evidence support it.
Use both when the questions differ
A practical design may use public devices for occasional breadth and dedicated devices for repeatable or sustained workloads. They also differ in how they are organized: a public device cloud is typically accessed through a provider-operated service, while a dedicated fleet is capacity reserved for one customer or operated in a customer-controlled environment. The operating arrangement determines who provisions, schedules, maintains, and supports the devices. It does not imply that both resource types share a management system.
A team may connect them through a common scheduler or analysis pipeline when the service supports that arrangement or the team explicitly builds the integration. Otherwise, they can remain separately managed and be assigned to different workloads. Neither model is inherently more secure; evaluate identity and access controls, data flows, support access, and retention for the actual deployment. If a workload has strict privacy requirements, place it only in an environment that meets them.
Some services may offer a mixed-pool feature that exposes public and private devices within that service; AWS Device Farm documents one such configuration. This is a service-specific option, not a default relationship between public and dedicated fleets. Verify availability for the relevant region and devices, and check that its data path and controls meet the workload’s requirements.
If the team chooses to integrate the pools, define the handoff explicitly. Keep environment, device, and run metadata with each attempt; specify which results can be compared; and do not move sensitive fixtures or evidence into another environment just to simplify reporting. A shared task system is one possible design when it is deliberately implemented and its access and data policies fit both environments; separate systems are also valid.
Where dedicated infrastructure fits
For teams that need recurring, controlled work on physical Android devices, dedicated infrastructure can provide a stable execution base alongside a broader public catalog. ARMARRAY’s S32 is a standard 32-node physical Android configuration with a platform layer and private-deployment options. The infrastructure can serve as the execution layer for a customer’s internal workloads, or as the device foundation on which a customer builds and operates its own device service. Teams can bring their app tests, agents, or automation workflows; custom development can be scoped separately. The standard cohort supports a defined operating model and does not claim to replace every device in a broad compatibility catalog.
There is no single model for every workload. Where a strict privacy requirement applies, it constrains the acceptable data path; otherwise, duration, peak concurrency, device diversity, operating responsibilities, and the cost of evidence-complete results may drive the choice. Use public access, dedicated capacity, or both—and preserve enough context to know what each run actually proves.