- The Platform Configurator
- Getting Started with Selenium for Automated Website Testing
- Getting Started with Appium for Mobile Native Application Testing
- Selenium Bootcamp by Dave Haeffner
- Appium Bootcamp by Dave Haeffner and Matthew Edwards
This topic describes the Appium capabilities to use in your real device tests.
Different Behaviors from Local Server Testing
Some Appium capabilities behave differently when running Appium tests in the real device cloud instead of against a local Appium server, including :
- All the emulator-only capabilities will not work
appcapability is always overwritten to point to the app file you uploaded to our system
noResetcapability only works if device caching is enabled. By default,
noResetis set to
- For test suite runs, the
namecapabilities are ignored
Different setups might have slightly different ways of handling capabilities and/or different requirements. You should also check the examples for your specific setup to make sure you are providing all required capabilities.
Required Capabilities for Real Device Testing
Your Appium scripts for real device testing must include these capabilities. Check out the example script in Dynamic Allocation Examples for examples of these capabilities and their values.
|The API key you use to authenticate your tests. You can find this in the Appium setup instructions for your project.|
The ID of the application you want to test. To find the ID for your application, log into https://app.testobject.com and select the app you want to test. In the Active Version panel, click All Versions. You will find the
Installing App Dependencies
You can install an application dependency on the same device by passing an array of app ids, for example
Optional Capabilities for Real Device Testing
The version of Appium you want to use in your tests.
|A name for your test, to make it easier to find individual tests|
Capabilities for Dynamic Allocation of Devices
Values are Not Case Sensitive
The values for capabilities are case-insensitive, so
"android" is the same as
"ios" is the same as
With dynamic allocation, you provide 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.
Set the capabilities
platformVersion to dynamically allocate any type of a device with those specifications to your test run. You must specify both capabilities.
|The type of mobile platform to use in your tests, for example "|
|The platform version to use in your tests, for example "|
If you only want to test on a particular type of device, such as a Samsung S7 or an iPhone, set
deviceName to the display name of the device as shown in the Real Devices menu of the Sauce Labs web interface.
|The display name of the device to use, such as |
Using Regular Expressions for deviceName
You can also use regular expressions for setting the
deviceName . For example:
"iPhone .*" will allocate any iPhone.
.*nexus.*" will allocate any device with the word "nexus" in its display name.
"iPhone " or
"iPhone [6-7]" will allocate either "iPhone 7" or "iPhone 6" device.
"iPhone S" or
"iPhone [6-7]S" will allocate either "iPhone 7S" or "iPhone 6S" device.
"iPhone 7.*" will allocate "iPhone 7" or "iPhone 7S", or any device that starts with the display name "iPhone 7"
Regular expressions are case insensitive, for example,
"iphone .*S" and
"IPHONe .*s" are the same.
Optional Capabilities for Dynamic Allocation
If you have access to both private and public devices, you can request allocation of private devices only.
You can use the
phoneOnly desired capabilities to select only phone or tablet devices.
You can use the
carrierConnectivityOnly desired capability to allocate only devices that are connected to a carrier network.
Dynamic Allocation Examples
Capabilities for Static Allocation of Devices
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.
Set the capability
deviceName to the ID of the device to allocate a specific type of device to use in your tests. The
platformVersion capabilities will be set by default, and if these are included in your test script, they will be ignored.
|The ID of the device you want to use in your test, for example "|
Device Caching and Resetting Applications
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.
|A random string. This value for |
Using Device Caching with
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 uninstalled 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 while
testobject_cache_device is set to
true, no device cleaning will take place in between sessions, regardless of
Set the following capabilities to use UIAutomator2 with Appium (Android native apps only)
Live View and Report URLs
Set these capabilities to view your test while it's running, and to view the report when it completes.
|The URL to the live view of your test execution|
|The URL to Appium test report generated when the test completes.|
Public URL to API for Test Details
Use this capability to get access to test details such as test information, video, and screenshots via the Sauce Labs API.
|The URL to the test report|
Session Creation Timeout
When creating an Appium session on the real devicepublic cloud, it may be the case that the device you want to test against is "in use" and not currently available for testing. When this happens, the tests will wait for 15 minutes to create a session on the device by default. If you want to set a custom timeout for session creation, you can do so using the desired capability
|A string containing the desired timeout in milliseconds. The maximum allowed timeout is 30 minutes.|
WebDriverAgent Timeout for iOS Devices
When creating an Appium session on the real device cloud for any iOS device, it is possible to set the desired capability
commandTimeouts . It will set a timeout for the WebDriverAgent backend which will prevent automated test sessions from being blocked when the Appium WebdriverAgent backend freezes unexpectedly. TestObject sets a default of 60 seconds for this capability. If it is necessary it is possible to set a lower value by setting the desired capability.
|Custom timeout in milliseconds for the WDA backend. The maximum allowed timeout is 60,000 seconds.|
Patched Chromedriver for Use with Crosswalk
As described in Appium Issue 4597 and Chromedriver Issue 2375613002, mobile tests using Crosswalk will fail because because of attempts to connect to the wrong socket on the device. Sauce Labs has developed a patched version of Chromedriver that will work with Crosswalk. You can specify to use this patched version with the
crosswalkApplication desired capabilitiy.
By default, applications are installed on devices in the Sauce Labs real device cloud with the
autoGrantPermissions desired capability set to
true, as long as the API number of the device is equal to 23 or higher. You can disable this by explicitly setting
By default, animations are disabled on real devices. You can enable animations for private cloud devices only with the