Device Allocation
Dynamic Allocation involves providing basic parameters for the platform and operating system, or the type of device you want to use in your tests, and a device with those specifications is selected from the device pool. While static allocation allows you more fine-grained control over the device used in your tests, it can also cause delays in your test execution if that device isn't available when you run your tests. If you only need to test on a particular platform and OS version, such as an Android 4.1, or on a particular type of device, you should use dynamic allocation, and we recommend that you use dynamic allocation for all automated mobile application testing in CI/CD environments.
Required Capabilities for Dynamic Allocation
Capability | Capability Explanation |
|---|---|
platformName | The type of mobile platform to use in your tests, for example Values are NOT case sensitive The values for capabilities are case-insensitive, so |
platformVersion | The platform version to use in your tests, for example Version Matching This is a substring match. You can specify both major versions and incremental versions of an operating system. For example if you set only a major version This also extends to minor and point versions. For example if you specify |
deviceName | The display name of the device to use, such as Using Regular Expressions for deviceName You can also use regular expressions for setting the For example:
Regular expressions are case insensitive, for example, |
Optional Capabilities for Dynamic Allocation
privateDeviceOnly | If you have access to both private and public devices, you can request allocation of private devices only with "true" | |
Capability | Capability Explanation | |
|---|---|---|
tabletOnly | Select only tablet devices with "true" | |
phoneOnly | Select only phone devices with "true" | |
carrierConnectivityOnly | Only allocate devices if they are connected to a carrier network with "true" |
With Static Allocation, you can specify the device to use in your tests, but if that device is not available when you run your tests, it will delay test execution. For this reason, you should always make sure that the device you want to use is available before launching your tests. The
platformName and platformVersion capabilities will be set by default, and if these are included in your test script, they will be ignored.| Capability | Setting |
|---|---|
deviceName | The ID of the device you want to use in your test, for example "LG_Nexus_5X_real". You can find the ID for a device by locating it in the real device selection menu of the Sauce Labs application, and then click the Details link for the device. |
Device Caching
testobject_cache_device Capability Deprecated
Previous versions of the Real Device Cloud platform used the capability testobject_cache_device to keep the device allocated to you during the cleaning process, but you could only use this capability for static allocation. This has been deprecated and replaced with the capability cacheId, described in this section, which works for both static and dynamic allocation. If you have scripts that use testobject_cache_device, they will still work for static allocation, and the 10 second limit on cached devices is still the same.
By default, every time you complete a test session, the real device cloud uninstalls your application, performs device cleaning, and de-allocates the device. This means that if you have multiple tests that you want to run on the same device, you will, by default, wait for this cleaning process to complete between every test. However, you can use the capability cacheId to leave the device allocated to you for 10 seconds after each test completes. If you immediately start another test on the device, you won't need to wait for the allocation and device cleaning process to be repeated. In this case, no device cleaning will take place in between sessions, with the only exception being the application under test and the data it owns.
| Capability | Setting |
|---|---|
| A random string. This value for cacheId must be the same for all test methods that you want to run on the cached device. In addition, the application and project ID used for the tests must remain the same, along with the values for these capabilities:
|
Using Device Caching with noReset
You can also use the cacheId capability in conjunction with the standard noReset Appium capability. In the default case, where noReset is set to false, your application will be uninstalled and reinstalled after every test. If noReset is set to true, the application you are testing won't be reinstalled after every test run. This might save you further time, but it won't be suitable for test setups that require the application's state to be reset between tests. Note that then cacheId is set, no device cleaning will take place in between sessions, regardless of noReset value.
Overview
Content Tools
Activity