Devices
The three places a Drizz test runs — your Mac, the Drizz device cloud, or your org's private devices — and what happens when none is free.
A test runs in one of three places: on your own Mac, on the Drizz device cloud, or on devices reserved for your organization.
Platforms
Android · iOS
Three types
Local · Cloud · Private
Session isolation
Every test gets its own device session
No device free
The run waits — it doesn't fail. Wait reason pool_exhausted
Watch out
Local runs one test at a time. Parallelism only exists in the cloud
Prerequisites
Drizz desktop app installed and signed in, for local devices
A test plan, for cloud and private devices
Private devices arranged with your Drizz contact
Device types
Local
Cloud
Private
Where
Your Mac — emulator, simulator, or a USB device
The Drizz device cloud
Your own devices, reserved for your org
Applies to
Authoring and debugging
Regression, parallel runs, device coverage
Compliance, specific hardware, SIM and carrier testing
Parallelism
One test at a time
Many tests at once
Bounded by device count
Queuing
None — starts immediately
Waits when nothing is free
Waits when nothing is free
Device range
Whatever you have
A catalogue of models and OS versions
Exactly your hardware
App install
Whatever is on the device
The registered build the plan points at
The registered build the plan points at
Set up by
You, once, via the guided wizard
Nothing to set up
Arranged with your Drizz contact
Getting a device
Open the guided wizard in the desktop app — see Set up a device: guided wizard.
Complete setup for your emulator, simulator or USB device.
Open the Connect Device screen and select the device.
Confirm it shows as connected.
Local devices run one test at a time and never queue.
Open Integrations.
Authorise.
List of devices and OS will be shown which creating testplan.
Sessions are isolated
Every test gets its own device session. A 10-wide run is ten separate sessions, not ten tests sharing a device.
Parallel tests cannot contaminate each other. One test's login state, cache or leftover data is invisible to the others.
Test order within a plan is about dependency, not cleanup.
State carried between tests must be explicit — a shared login module, or a dataset value.
Waiting, and pool_exhausted
When nothing is free, a run waits rather than failing, and reports a wait reason.
pool_exhausted
No device is free, or every row of a lockable pool is leased
Waiting with devices idle
The block is data, not hardware — check your lockable pool size
A wait times out. Runs that repeatedly wait have one of three causes: insufficient device capacity, concurrency set above capacity, or a lockable pool smaller than concurrency.
Limits
Location
Set when a cloud device is provisioned. Cannot be changed mid-test
Precise location permission
Not grantable on every device — see Known limitations
Common mistakes
Raise concurrency to clear a queue
If the block is a lockable pool, more concurrency adds waiting, not throughput
Assume a run used the device you asked for
It may have fallen back. Read the device recorded on the run
Debug a failing test on cloud devices
Slower, and you can't watch the screen. Reproduce locally
Rely on one test cleaning up for the next
Sessions are isolated. Make shared state explicit
Treat a waiting run as a failure
It's queued. It will start or time out
Compare pass rates across different device models
Device-specific failures read as flakiness
Next
Last updated: 6 August 2026
Last updated
Was this helpful?