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 and names it does not return the devices inside each pool to retrieve devices from one pool, list devices with the pool id filter in an sdk version that transmits filters 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 a record contains metadata such as filekey , downloadurl , timestamps and duration recording delivery can use http live streaming compatible with rfc 8216 when configured by the device park environment 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 continue run the guided sdk flow docid\ bmzpbcohqbrc7rfyomonachoose and filter devices docid\ t2lfrssg2mhohpoa4k26 create an allocation docid\ spz n5rutgomdkrbjbb0lstart and reuse sessions docid\ ousu3hjjbqlfsc2burfu list screen recordings docid 9vofjqy3nq7olg4uhlhtk