How Device Park Works
Mobile test teams rarely struggle only with reaching a device. The larger challenge is turning device access into a predictable test operation as test plans grow, scenario counts increase and parallel execution becomes necessary.
Device Park separates resource access from test execution. Instead of making one technical session responsible for the complete test plan, it coordinates three layers:
Layer | Responsibility |
|---|---|
Allocation | Reserves a device for the test workflow |
Device Park session | Defines and tracks a managed test interaction period |
Appium session | Executes automation commands through the Appium client |
This separation gives test runners explicit control over reservation, execution, retries, evidence and cleanup.
Reserve the Device Before Testing
An allocation secures the device resource before a Device Park session starts. It removes the race between finding a suitable device and attempting to use it.
The allocation can target:
- one exact device with serial
- any available device in a pool with devicePoolId
- a device matching platform and hardware criteria
If a matching device is not immediately available, the allocation can wait in a queue. The same allocationId represents that request while it is waiting and after a device is assigned.
Store the first allocationId and inspect that allocation while waiting. Creating duplicate allocations can reserve additional devices or create additional queue entries.
Start Within the Allocation Window
An allocation is temporary. Its response includes expiresAt, which tells the test runner when the reservation expires.
Start the Device Park session while the allocation is active. Environment-level idle timeout policies can also limit how long an allocated device remains unused. The exact timeout is controlled by the Device Park environment and is not hard-coded by the SDK.
Stopping a Device Park session does not automatically release the allocation. If the allocation remains active, another session can be started with the same allocationId.
Separate Device Park and Appium Sessions
A Device Park session is the managed operational layer. It stores allocation linkage, device information, recording configuration, Appium version and timestamps.
An Appium session is the technical automation layer created by the Appium client. Appium commands are sent by the test framework, not by the Device Park SDK.
Keeping these layers separate allows a test plan to renew technical Appium execution when needed without treating the device reservation as disposable. The exact number and concurrency of Appium sessions allowed inside a Device Park session depends on the environment configuration.
Reuse One Allocation for Multiple Scenarios
Long regression plans do not need to reserve a new device for every scenario. A common sequence is:
- Create one allocation.
- Start a Device Park session.
- Run the scenario through Appium.
- Stop the Device Park session.
- Start another session with the same active allocationId.
- Release the allocation after the final scenario.
This keeps device selection stable while each scenario has an independent managed session and evidence set.
Organize Capacity with Pools
A pool is a logical group of devices managed by Device Park. Pools help teams divide capacity by platform, project, customer or test purpose.
List Pools returns pool identifiers, names and default-pool status. It does not return the devices inside each pool. To retrieve devices from one pool, list devices with the POOL_ID filter.
Pool-based allocation is useful when the exact serial does not matter. It gives Device Park flexibility to select an available device from the requested group.
Record and Review Sessions
Set videoRecording to true when starting a Device Park session to enable screen recording.
After the session is finalized, list its screen records with the returned sessionId. Each record contains metadata for one stored media segment, such as fileKey, downloadUrl, timestamps and duration. For complete-recording playback, use the finalized session's videoRecordUrl; it identifies an RFC 8216-compatible HLS media playlist that orders those segments. See List screen recordings for browser playback and authorization guidance.
Use recordings to review failures, validate scenario behavior and share evidence without keeping the test runner connected.
Operational Lifecycle
flowchart TD
target["Choose device, pool or criteria"] --> allocation["Create allocation"]
allocation --> ready{"Device assigned?"}
ready -- "No" --> inspect["Inspect the same allocation"]
inspect --> ready
ready -- "Yes" --> session["Start Device Park session"]
session --> appium["Run Appium automation"]
appium --> stop["Stop Device Park session"]
stop --> more{"More scenarios?"}
more -- "Yes" --> session
more -- "No" --> evidence["Collect logs and recordings"]
evidence --> release["Release allocation"]Device Park turns mobile testing into a managed lifecycle:
- allocation makes resource use predictable
- sessions make test execution observable
- Appium remains the automation engine
- pools organize capacity
- cleanup returns devices safely to the team