---
title: How Device Park Works
slug: devicepark/sdk-documentation/getting-started/how-device-park-works
description: Understand how Device Park turns managed device access into scalable mobile test execution.
docTags: 
createdAt: 2026-08-10T08:03:45.197Z
---

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.

:::hint{type="warning"}
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:

1. Create one allocation.
2. Start a Device Park session.
3. Run the scenario through Appium.
4. Stop the Device Park session.
5. Start another session with the same active `allocationId`.
6. 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](docId:9voFjQy3NQ7olg4uHLhTK) 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

```mermaid
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

## Continue

- [Run the guided SDK flow](docId\:BmZpbcOhqBrc7RFyOMona)
- [Choose and filter devices](docId\:T2lFRSsG2mhohPOA4K26-)
- [Create an allocation](docId\:sPz_N5rutGOmDKrBjbb0L)
- [Start and reuse sessions](docId\:ouSu3HjjBQLFsC2bURFU-)
- [List screen recordings](docId:9voFjQy3NQ7olg4uHLhTK)