A Complete Tutorial to Appium Capabilities for Mobile Automation
Wasiq Bhamla
Posted On: July 28, 2023
158338 Views
31 Min Read
Capabilities are a set of parameters that describes the device on which the Appium test should run, along with the application to be used for testing. These capabilities must be provided to the Appium Server while creating the session. With these capabilities, the Appium Server parses them and creates the session with the target device described in the capabilities, and installs or launches the target application on the device before our test starts executing.
Before we go into more detail with capabilities, let’s first understand Appium. Appium is an open-source mobile application testing framework and a complete ecosystem to help automate Android and iOS applications categorized across different mobile-based applications, like Native, Web, and Hybrid. It also supports automating Smart TV and Windows and macOS-based desktop applications.
Appium consists of two core components. The first is the Appium Server command line library, a NodeJS-based library that completely manages the Appium session created with the device. The second component is the Appium Client, which is available in multiple programming languages like Java, Python, JavaScript, etc. The client is responsible for communicating with the Appium Server and providing it with instructions about how to communicate with the application on the target device and test it.
Capabilities are used with these Appium Clients, which consume the capabilities provided to them and pass on these capabilities to the Appium Server, which in turn understands them and starts the mobile device session based on these capabilities.
In addition to leveraging Appium’s capabilities for interactions and validations, integrating Appium Visual Testing allows you to extend your testing horizon to include visual regressions. By automatically capturing and comparing UI screenshots between baseline and current versions, Appium Visual Testing helps identify even the subtlest visual discrepancies that might impact user satisfaction. This comprehensive approach not only ensures that your app functions as intended but also maintains its visual integrity across iterations.
In this blog on Appium Capabilities, we will be using Appium 2.0. To understand what changes Appium 2.0 brings in from Appium 1.x, it has decoupled Appium drivers from its command line tool. Earlier, it used to install all the available drivers when you installed the Appium command line tool. But with Appium 2.0, only the command line tool will be installed, while you can install only those drivers you want to use.
If you are using Appium 1.x and want to learn more about Appium 2.x or even switch to it, you can go through this Appium 2 migration guide.
In this tutorial on Appium Capabilities, we will cover different types of capabilities for Android and iOS platforms:
- Common Appium capabilities, which are common irrespective of the target platform.
- Platform-specific Appium capabilities, which are platform-specific, like Android has its own set of capabilities, and iOS has its own.
- Driver-specific Appium capabilities, which are driver-specific, like the UiAutomator2 driver will have different capabilities than the Espresso driver.
- Cloud platform-specific Appium capabilities, which are cloud provider specific and will differ from one cloud provider to another.
Appium Client libraries for different languages have different options classes created, which helps set many of these capabilities directly by exposing descriptive methods representing the corresponding capability name. So most of the time, you will call the respective method and pass the required value for the capability directly to that method. Once all the Appium capabilities are set, you will pass the options object instance to the corresponding driver class while creating the driver instance.
TABLE OF CONTENTS
Common Appium Capabilities
The common capabilities are the ones that can be used for any platform you are automating with Appium. Let’s see the commonly used Appium capabilities irrespective of your working platform.
Note: While looking into these Appium capabilities, we will use the UiAutomator2Options class for examples of how to set these capabilities in the test. However, when you work on any particular platform, you will use the corresponding options class depending on your working platform.
platformName
In this capability, you will give the target platform name, which can be Android or iOS, depending on which platform is being automated. This capability is mandatory and must be provided to Appium.
If you use any of the available option classes and initialize it, this capability will be automatically set under the hood along with the automationName capability, so you don’t need to set it explicitly.
Following is the table which lists all the option classes along with their corresponding platform and automation name values which are automatically set when you use the option class:
Option class | Platform Name | Automation Name |
---|---|---|
UiAutomator2Options | Android | UiAutomator2 |
EspressoOptions | Android | Espresso |
XCUITestOptions | iOS | XCUITest |
Mac2Options | Mac | Mac2 |
WindowsOptions | Windows | Windows |
For example, in the following code snippet, when we initialize the UiAutomator2Options options class, the platformName, and appium:automationName capabilities will get set to Android and UiAutomator2 respectively.
1 |
var options = new UiAutomator2Options (); |
appium:automationName
This capability instructs Appium which Appium driver it must use to automate the application. It is a mandatory capability and must be set to run the tests. This capability is automatically set along with platformName when you use any available option classes, as explained earlier.
appium:platformVersion
This capability holds the target platform version number. It is an optional capability. If provided, it will help Appium narrow the search for the correct device. Check out the following code snippet on how to set the platform version capability using the option class:
1 2 3 |
var options = new UiAutomator2Options (); options.setPlatformVersion ("12"); // ... Other capabilities |
For example, in the case of Android, you can mention any Android version you want to automate, like 12 or 11. In the case of iOS, you can mention the exact version, like 16.2.
browserName
If you want to automate a web application, you can use this capability to set on which browser you want to test that web application. If you use this capability, you can avoid using appium:app capability.
1 2 3 |
var options = new UiAutomator2Options (); options.withBrowserName (Browser.CHROME.browserName ()); // ... Other capabilities |
Test your websites using Appium across 3000+ mobile browsers. Try LambdaTest Today!
appium:app
If you want to automate a native or a hybrid application, you can use this capability to set the path to the *.apk file on your machine for Android, *.ipa file path for iOS real device or *.app.zip / *.app file path for iOS simulator.
1 2 3 4 5 6 |
private static final String USER_DIR = getProperty ("user.dir"); var options = new UiAutomator2Options (); options.setApp (Path.of (USER_DIR, "src/test/resources/apps/wdio-demo.apk").toString ()); // ... Other capabilities |
appium:deviceName
This capability is where you would give the device name on which you will be testing your application. This capability is not used internally for Android. However, it is used to find the target device in the case of iOS. So you must make sure you give the correct device name for iOS.
For example, you may give the iPhone 14 Pro device name for the iOS device.
1 2 3 |
var options = new UiAutomator2Options (); options.setDeviceName ("Pixel_6_Pro"); // ... Other capabilities |
appium:noReset
If this capability is set with the value as true, it will indicate the driver to skip its clean-up and reset logic from being applied at the start of the session. By default, the value is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.setNoReset (true); // ... Other capabilities |
appium:fullReset
If this capability is set with the value as true, it will instruct the Appium Server to do a complete reset of the device by deleting whatever temporary data which was created due to the previous executions including the applications which were installed before along with cleaning up any previous logs which are there on the device.
Full reset does not mean that Appium will simply wipe out the complete data of the device. It will only delete the files created by Appium when the test is executed. This ensures maximum environmental reproductivity. By default, the value is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.setFullReset (true); // ... Other capabilities |
appium:eventTimings
If this capability is set as true, it will instruct Appium to collect all the event timings each event takes to execute. By default, the value is set as false.
When this capability is enabled, you can get details of all the events and commands executed by Appium, along with the timings each of those events and commands took to execute.
1 2 3 |
var options = new UiAutomator2Options (); options.setEventTimings (true); // ... Other capabilities |
Once this capability is enabled, you can get event details using the following code example:
1 |
driver.getEvents (); |
appium:printPageSourceOnFindFailure
If the capability is set as true, it will instruct to print the complete page source when Appium fails to find any element. By default, the value is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.setPrintPageSourceOnFindFailure (true); // ... Other capabilities |
appium:udid (optional, default: null)
This capability takes in the unique device ID of the target device on which you will be executing your test. For Android, you can get the UDID of the device by running adb devices -l on your terminal, as shown below:
For iOS, you can get it from Xcode > Windows > Devices and Simulators > Simulators (see the reference screenshot below).
This capability is optional. If not provided, it will automatically find the device matching other Appium capabilities you have provided. But this capability must be provided if there is more than one real device with the same iOS versions connected to the machine. Appium will try finding the particular device matching the provided unique ID.
1 2 3 |
var options = new UiAutomator2Options (); options.setUdid ("emulator-5554"); // ... Other capabilities |
appium:settings[ < setting-name > ]
With this capability, you can apply any of the available Appium settings which you would otherwise use driver.setSetting (“settingName”, “settingValue”); after the session is started. Using this capability, you can replace the < setting-name > with the actual setting name and assign the value of that setting.
1 2 3 |
var options = new UiAutomator2Options (); options.setCapability ("appium:settings[ignoreUnimportantViews]", true); // ... Other capabilities |
You can get all the list of supported settings from the following driver documentations:
appium:enforceAppInstall
If this capability is set to true, then the application under test is always reinstalled even if a newer version of it already exists on the device under test. This is set to false by default.
1 2 3 |
var options = new UiAutomator2Options (); options.enforceAppInstall (); // ... Other capabilities |
appium:language
This capability sets the application language based on the format of the ISO-639 code for alpha-2 or alpha-3 language code. To illustrate, when configuring the application language to French, you should set the capability as “fr,” while for English, it will be “en.” The device’s system language will be utilized by default.
1 2 3 |
var options = new UiAutomator2Options (); options.setLanguage ("fr"); // ... Other capabilities |
appium:locale
This capability sets the application language based on the format of ISO-3166 two-letter country code or three-digit country code. By default, the device system locale will be used. For example, if you want to set the locale to France, you must set the value as FR or 250.
1 2 3 |
var options = new UiAutomator2Options (); options.setLocale ("FR"); // ... Other capabilities |
appium:otherApps
You can provide a comma-separated list of one or more applications that you want to install before you run your test because they are the dependent applications on which the application under test relies on.
1 2 3 4 5 6 7 8 |
private static final String USER_DIR = getProperty ("user.dir"); var otherApp1 = Path.of (USER_DIR, "src/test/resources/apps/otherApp1.apk").toString (); var otherApp2 = Path.of (USER_DIR, "src/test/resources/apps/otherApp2.apk").toString (); var options = new UiAutomator2Options (); options.setOtherApps (otherApp1 + "," + otherApp2); // ... Other capabilities |
appium:isHeadless
If you want to run your test in a headless mode on any virtual device, whether it’s on Android Emulator or iOS Simulator, then you must set this capability as true. By default, this capability is set to false.
1 2 3 |
var options = new UiAutomator2Options (); options.headless (); // ... Other capabilities |
appium:skipLogCapture
If you want to enforce Appium to skip capturing the logs during the test execution, then you must set this capability as true. This would improve network performance. If this capability is enabled, then any log-related commands will not work. By default, this capability is set to false.
1 2 3 |
var options = new UiAutomator2Options (); options.skipLogcatCapture (); // ... Other capabilities |
appium:newCommandTimeout
Maximum amount of time in seconds should Appium driver wait for a command from the client to get executed before assuming that the client is no longer active. By default, 60sec is set for this capability. This capability is not supported by the Android Espresso driver.
1 2 3 |
var options = new UiAutomator2Options (); options.setNewCommandTimeout (Duration.ofSeconds (10)); // ... Other capabilities |
appium:mjpegServerPort
The number of the port the Appium server starts the MJPEG server on. If not provided, then the screenshots broadcasting service on the remote device does not get exposed to a local port (e.g., no adb port forwarding is happening). This capability is not supported by the Android Espresso driver. You can learn more about it through this blog on ADB commands.
1 2 3 |
var options = new UiAutomator2Options (); options.setMjpegServerPort (9200); // ... Other capabilities |
Platform-Specific Appium Capabilities
Apart from the common capabilities seen earlier, some platform-specific Appium capabilities are common throughout that platform. Let’s check out all these capabilities for each of the platforms.
Following are Android-specific capabilities that are commonly supported irrespective of the driver you might be using whether UiAutomator2 or Espresso drivers.
appium:systemPort
This is the port number on which the corresponding Android driver listens. By default, any of the 8200-8299 free port numbers will be used. But if you want to execute your tests in parallel, you must ensure that you provide a unique systemPort number capability.
1 2 3 |
var options = new UiAutomator2Options (); options.setSystemPort (8250); // ... Other capabilities |
appium:skipServerInstallation
If you set this capability as true, then the driver will skip the server component installation on the device along with any related checks. This will help speed up the test execution only when you are sure your target device already has the correct server component installed.
In case you are running for the first on any device, you must keep this capability disabled to make sure all the required Appium server components get installed. By default, the value is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.skipServerInstallation (); // ... Other capabilities |
appium:appPackage
This capability will try to launch the application with the same package name as provided to the capability. If this capability is not provided, Appium will find the application package name from the appium:app capability.
1 2 3 |
var options = new UiAutomator2Options (); options.setAppPackage ("packageName"); // ... Other capabilities |
appium:appActivity
Appium will try to launch the application activity which matches the provided capability. If not provided, Appium will automatically identify the main activity from the appium:app capability.
1 2 3 |
var options = new UiAutomator2Options (); options.setAppActivity ("activityName"); // ... Other capabilities |
appium:appWaitActivity
The activity name for which Appium should wait till it gets launched. If not provided, then by default appium:appActivity value is used.
1 2 3 |
var options = new UiAutomator2Options (); options.setAppWaitActivity ("activityName"); // ... Other capabilities |
appium:appWaitPackage
The package name for which Appium should wait till it gets launched. If not provided, then by default appium:appPackage value is used.
1 2 3 |
var options = new UiAutomator2Options (); options.setAppWaitPackage ("packageName"); // ... Other capabilities |
appium:appWaitDuration
The wait timeout in milliseconds for which Appium should wait until the application under test gets launched. By default, 20000 ms is used.
1 2 3 |
var options = new UiAutomator2Options (); options.setAppWaitDuration (Duration.ofSeconds (30)); // ... Other capabilities |
appium:androidInstallTimeout
This is the maximum amount of time Appium will wait till the application under test is installed on the device. By default, Appium will wait till 90000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setAndroidInstallTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:autoGrantPermissions
If this capability is set to true, then Appium will automatically grant any permissions which the application under test may request when it is first installed and launched, else, you will see the permissions pop-up whenever the application under test starts for the first time. By default, this is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.autoGrantPermissions (); // ... Other capabilities |
appium:uninstallOtherPackages
You can provide a comma-separated list of one or more applications you want to uninstall before you run your test on that target device.
1 2 3 |
var options = new UiAutomator2Options (); options.setUninstallOtherPackages ("package1,package2"); // ... Other capabilities |
appium:allowTestPackages
If you set this capability to true, then it would be possible to use packages built with the test flag for automated testing, which means it adds -t flag to the adb install
command. This is set as false by default.
1 2 3 |
var options = new UiAutomator2Options (); options.allowTestPackages (); // ... Other capabilities |
appium:remoteAppsCacheLimit
This capability sets the maximum amount of application packages to be cached on the device under test. This is needed for devices that don’t support streamed installs, for example, Android 7 and below, because adb must push app packages to the device first to install them, which takes some time. Setting this capability to 0 disables app caching, which is not required for Android 8 and above because that supports streamed installation. By default, this capability is set as 10.
1 2 3 |
var options = new UiAutomator2Options (); options.setRemoteAppsCacheLimit (10); // ... Other capabilities |
appium:adbPort
This capability sets the port number on which ADB is running. By default, Appium will listen on the 5037 port number.
1 2 3 |
var options = new UiAutomator2Options (); options.setAdbPort (8400); // ... Other capabilities |
appium:remoteAdbHost
This is the host address on which ADB will be running.
1 2 3 |
var options = new UiAutomator2Options (); options.setRemoteAdbHost ("http://localhost:9300"); // ... Other capabilities |
appium:adbExecTimeout
This will be the maximum amount of time in milliseconds Appium will wait for a single ADB command to get executed. By default, this capability value is set as 20000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setAdbExecTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:clearDeviceLogsOnStart
If this capability is set as true, then the corresponding Appium driver will clear all the logs from the device buffer before the test gets executed.
1 2 3 |
var options = new UiAutomator2Options (); options.clearDeviceLogsOnStart (); // ... Other capabilities |
appium:suppressKillServer
If this capability is true, then the Appium driver will not explicitly kill the ADB server. This capability is useful to be enabled when you have connected your target device via WiFi. By default, this capability is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.suppressKillServer (); // ... Other capabilities |
appium:avd
You can set the name of the Android emulator to run the test on. The names of currently created emulators could be listed using the emulator -list-avds
command. If the emulator with the given name is not running, it will be launched on automated session startup.
1 2 3 |
var options = new UiAutomator2Options (); options.setAvd ("Pixel_6_Pro"); // ... Other capabilities |
appium:avdLaunchTimeout
You can set the maximum amount of time in milliseconds Appium should wait for the Android Emulator to launch. By default, the capability is set to 60000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setAvdLaunchTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:avdReadyTimeout
You can set the maximum amount of time in milliseconds Appium should wait for the Android Emulator to be fully loaded and ready for running the tests. By default, the capability is set to 60000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setAvdReadyTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:avdArgs
You can pass the Android emulator arguments to this capability. Appium will use these arguments while starting the Emulator.
1 2 3 4 5 6 7 |
final var args = new ArrayList<String> (); args.add ("-gpu swiftshader_indirect"); var options = new UiAutomator2Options (); options.setAvdArgs (args); // ... Other capabilities |
appium:chromedriverPort
This capability sets the port number on which Appium will listen for Chrome driver communications. By default, this capability is unset.
1 2 3 |
var options = new UiAutomator2Options (); options.setChromedriverPort (9300); // ... Other capabilities |
appium:chromedriverExecutableDir
This capability will contain a full path to the folder where the downloaded Chrome driver executable is stored when Appium automatically downloads the driver.
1 2 3 |
var options = new UiAutomator2Options (); options.setChromedriverExecutableDir ("/path/to/driver/exe/folder"); // ... Other capabilities |
appium:chromedriverExecutable
This capability will contain the complete path to the Chrome driver executable.
1 2 3 |
var options = new UiAutomator2Options (); options.setChromedriverExecutable ("/path/to/driver/exe"); // ... Other capabilities |
appium:chromedriverArgs
You can provide the Chrome driver-specific arguments by using this capability which Appium will use when launching the browser on the device. This capability is an array of Chrome driver arguments.
1 2 3 4 5 6 7 |
final var chromeArgs = new ArrayList<String> (); chromeArgs.add ("some-args"); var options = new UiAutomator2Options (); options.setChromedriverArgs (chromeArgs); // ... Other capabilities |
appium:chromeOptions
This capability takes a map of Chrome options to customize the Chrome driver. Check out this documentation for a complete list of supported Chrome options.
1 2 3 4 5 6 7 |
final var chromeOptions = new ChromeOptions (); chromeOptions.setBinary ("/path/to/chrome/exe"); var options = new UiAutomator2Options (); options.setChromeOptions (chromeOptions.asMap ()); // ... Other capabilities |
appium:skipUnlock
When this capability is set to true, then Appium will not check if the device screen is currently locked. By default, it’s set as false, which means, Appium checks if the device is locked and tries to unlock the device if it’s locked.
1 2 3 |
var options = new UiAutomator2Options (); options.skipUnlock (); // ... Other capabilities |
appium:unlockType
You can provide the unlock type your device uses to unlock. This value can be any one of the following:
- pin: It is a numeric pin code
- password: It is an alphanumeric password
- pattern: It is a finger gesture pattern
- fingerprint: It is a fingerprint biometric
- pinWithKeyEvent: It is a numeric pin code which is entered using a key event
1 2 3 |
var options = new UiAutomator2Options (); options.setUnlockType ("pin"); // ... Other capabilities |
appium:unlockKey
You can set the unlock key which Appium can use to unlock the device with.
1 2 3 |
var options = new UiAutomator2Options (); options.setUnlockKey ("123456"); // ... Other capabilities |
appium:unlockSuccessTimeout
This is the maximum time in milliseconds Appium will wait for the device under test to get unlocked. By default, this value is set as 2000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setUnlockSuccessTimeout (Duration.ofSeconds (20)); // ... Other capabilities |
appium:disableWindowAnimation
If this capability is set to true, the device window animation will be disabled. By default, this capability is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.disableWindowAnimation (); // ... Other capabilities |
appium:noSign
When this capability is set to true, Appium will skip signing the application under test with the default Appium debug signature. You can disable the application signing if you want to test your application as is without any modification. By default, this capability is set as true.
1 2 3 |
var options = new UiAutomator2Options (); options.noSign (); // ... Other capabilities |
Following are the capabilities specific to the iOS platform.
appium:updatedWDABundleId
You can provide a bundle id to this capability, which Appium will use to update WDA before building and launching it on real devices. This bundle id must be associated with a valid provisioning profile. For example, you can set its value as io.appium.WebDriverAgentRunner.
1 2 3 |
var options = new XCUITestOptions (); options.setUpdatedWdaBundleId ("io.appium.WebDriverAgentRunner"); // ... Other capabilities |
appium:xcodeOrgId
This capability will take the Apple developer team identifier, which is a 10-character long string. This capability must be used in conjunction with appium:xcodeSigningId to take effect.
1 2 3 |
var options = new XCUITestOptions (); options.setCapability (IOSMobileCapabilityType.XCODE_ORG_ID, "XXXXXXXXXX"); // ... Other capabilities |
appium:xcodeSigningId
This capability is the string representing a signing certificate. It must be used in conjunction with appium:xcodeOrgId. This is usually just iPhone Developer, so the default (if not provided) is iPhone Developer.
1 2 3 |
var options = new XCUITestOptions (); options.setCapability (IOSMobileCapabilityType.XCODE_SIGNING_ID, "iPhone Developer"); // ... Other capabilities |
appium:webDriverAgentUrl
If you provide this capability a value, then Appium will connect to an existing WebDriverAgent instance at this URL instead of starting a new one. By default, http://localhost:8100 is used.
1 2 3 |
var options = new XCUITestOptions (); options.setWebDriverAgentUrl ("http://localhost:8100"); // ... Other capabilities |
appium:useNewWDA
If this capability is set to true, Appium will uninstall any existing WebDriverAgent application installed on the device and build and install the new instance of WDA.
For real devices, it is required for the WebDriverAgent client to run for as long as possible without reinstalling/restarting to avoid any issues. The false value, the default behavior, will try to detect the currently running WDA listener executed by previous testing sessions and reuse it if possible, which is highly recommended for real device testing and to speed up suites of multiple tests in general.
1 2 3 |
var options = new XCUITestOptions (); options.useNewWDA (); // ... Other capabilities |
appium:wdaLaunchTimeout
This capability takes time, in milliseconds, which Appium will wait until WebDriverAgent is launched. By default, Appium uses 60000 ms.
1 2 3 |
var options = new XCUITestOptions (); options.setWdaLaunchTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:wdaConnectionTimeout
This is the timeout in milliseconds which Appium will wait for the response from WebDriverAgent to respond. By default, 240000 ms is used.
1 2 3 |
var options = new XCUITestOptions (); options.setWdaConnectionTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:wdaStartupRetries
This is the number of times the Appium server will try to build and start up the WDA on the device before failing the test execution. By default, 2 is set for this capability.
1 2 3 |
var options = new XCUITestOptions (); options.setWdaStartupRetries (5); // ... Other capabilities |
appium:wdaStartupRetryInterval
This is the time interval between the retries for building and launching the WDA on the device in milliseconds. By default, 10000 ms is used.
1 2 3 |
var options = new XCUITestOptions (); options.setWdaStartupRetryInterval (Duration.ofSeconds (2)); // ... Other capabilities |
appium:wdaLocalPort
If you specify this capability value, Appium will use it to forward traffic from Mac host to real iOS devices over USB. By default, the value is the same as the port number used by WDA on the device.
1 2 3 |
var options = new XCUITestOptions (); options.setWdaLocalPort (8102); // ... Other capabilities |
appium:usePrebuiltWDA
If this capability is set to true, then Appium will not build the WebDriverAgent. It will be your responsibility to build the WDA manually. This feature is available for XCode v8 or above. By default, this capability is set to false.
1 2 3 |
var options = new XCUITestOptions (); options.usePrebuiltWda (); // ... Other capabilities |
appium:waitForIdleTimeout
This capability takes in the time in seconds in a floating number to wait until the application under test is getting idle. Since XCTest requires the main thread to be idle for the next command to get executed. The WDA will not even start or freeze if the application under test is constantly hogging the main thread. By default, Appium will use 10 seconds.
1 2 3 |
var options = new XCUITestOptions (); options.setWaitForIdleTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:maxTypingFrequency
The maxing keystrokes for typing or clearing the text in the element. If your test fails due to incorrect typing, you can try changing this capability. By default, this capability is set to 60 keystrokes per minute.
1 2 3 |
var options = new XCUITestOptions (); options.setMaxTypingFrequency (40); // ... Other capabilities |
appium:autoAcceptAlerts
This capability, when set to true, will instruct Appium to accept all the iOS alerts when they pop up automatically. This also includes all the privacy access permissions pop-ups. By default, this capability is set to false.
1 2 3 |
var options = new XCUITestOptions (); options.autoAcceptAlerts (); // ... Other capabilities |
appium:autoDismissAlerts
This capability, when set to true, will instruct Appium to dismiss any iOS alerts when they pop up automatically. This also includes all the privacy access permissions pop-ups. By default, this capability is set to false.
Following is the example code snippet on how to disable this capability:
1 2 3 |
var options = new XCUITestOptions (); options.autoDismissAlerts (); // ... Other capabilities |
appium:connectHardwareKeyboard
If you set this capability to true, then Appium will connect with the hardware keyboard on the Simulator. By default, this capability is set as false.
1 2 3 |
var options = new XCUITestOptions (); options.connectHardwareKeyboard (); // ... Other capabilities |
appium:simulatorStartupTimeout
You can set the timeout value in milliseconds which Appium will wait for the simulator to start up completely. By default, this capability is set as 120000 ms.
1 2 3 |
var options = new XCUITestOptions (); options.setSimulatorStartupTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:simulatorTracePointer
You can enable a pointer tracker on the simulator to see any touch or swipe gestures happening on the screen of the simulator by setting this capability to true. You must ensure that the simulator is shut down before applying this change, else this change will not reflect on the simulator. By default, this capability is set to false.
1 2 3 |
var options = new XCUITestOptions (); options.simulatorTracePointer (); // ... Other capabilities |
appium:permissions
You can provide any permissions your application under tests might need during your test execution. You must provide the value for this capability in the following format:
1 2 3 4 5 6 7 |
{ "<bundle_id_1>": { "<service_name_1>": "YES", // other services... }, //other bundle ids if available... } |
To check what service names you must use, then run this xcrun simctl privacy booted
on your terminal to get the supported service names.
You must set the corresponding service value by providing yes, no, or unset as values to grant, revoke or reset its corresponding permissions.
For example, you can set this capability value as {“com.apple.yourapp”: {“calendar”: “YES”}} to provide calendar permissions to your application under test.
1 2 3 4 5 6 7 8 |
var permissions = new HashMap<String, String> (); permissions.put ("calendar", "YES"); permissions.put ("contacts", "YES"); var options = new XCUITestOptions (); options.setPermissions (new Permissions ().withAppPermissions ("com.domain.app", permissions)); // ... Other capabilities |
appium:launchWithIDB
You can prefer to use IDB to launch WebDriverAgentRunner instead of the Xcode build tool by setting this capability to true. This will help improve the startup time because the Xcode build will be skipped. By default, this capability is set to false.
1 2 3 |
var options = new XCUITestOptions (); options.launchWithIdb (); // ... Other capabilities |
appium:clearSystemFiles
If you set this capability as true, then Appium will clear all the temporary files created by XCTest during the test execution, including logs. By default, this value is set to false.
1 2 3 |
var options = new XCUITestOptions (); options.clearSystemFiles (); // ... Other capabilities |
Driver-Specific Appium Capabilities
There are some capabilities in Appium specific to a particular driver type. Let’s check out all of these capabilities.
For Android, there are currently two drivers supported by Appium, these are UiAutomator2 and Espresso driver.
Following are the Appium capabilities specific to the UiAutomator2 driver:
appium:uiautomator2ServerLaunchTimeout
This is the maximum number of time in milliseconds Appium will wait for the UiAutomator2 server to launch on the device. By default, this capability is set as 30000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setUiautomator2ServerLaunchTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:uiautomator2ServerInstallTimeout
This is the maximum number of time in milliseconds Appium will wait for the UiAutomator2 server to be installed on the target device. By default, this capability is set as 20000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setUiautomator2ServerInstallTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:uiautomator2ServerReadTimeout
This is the maximum number of time in milliseconds Appium will wait for HTTP response to come from the UiAutomator2 server which is installed on the target device. By default, this value is set as 240000 ms.
1 2 3 |
var options = new UiAutomator2Options (); options.setUiautomator2ServerReadTimeout (Duration.ofSeconds (30)); // ... Other capabilities |
appium:skipDeviceInitialization
This capability, when set to true, then Appium will skip all the device checks and initialization steps. If you are sure that the initialization steps have already run properly before, then you can enable this capability to speed up the session creation step by skipping the device initialization step. By default, this value is set as false.
1 2 3 |
var options = new UiAutomator2Options (); options.skipDeviceInitialization (); // ... Other capabilities |
appium:autoLaunch
This capability, if set to false, will restrict Appium from launching the application under test when starting a new session on the device. By default, this capability is set as true.
1 2 3 |
var options = new UiAutomator2Options (); options.setCapability (AndroidMobileCapabilityType.AUTO_LAUNCH, true); // ... Other capabilities |
Following are the Appium capabilities that are specific to the Espresso driver:
appium:espressoServerLaunchTimeout
This capability is the maximum time in milliseconds Appium will wait for the Espresso server to get launched on the device under test. By default, this value is set as 45000 ms.
1 2 3 |
var options = new EspressoOptions (); options.setCapability ("appium:espressoServerLaunchTimeout", 40000); // ... Other capabilities |
appium:forceEspressoRebuild
This capability, when set to true, then Appium will rebuild the Espresso server .apk file every time the session is created. By default, this capability is set as false, which means Appium will only rebuild the Espresso server APK file when required or use the server APK from the cache.
1 2 3 |
var options = new EspressoOptions (); options.forceEspressoRebuild (); // ... Other capabilities |
appium:espressoBuildConfig
This capability would contain the full path of JSON config containing the Espresso config, or it can contain the JSON string itself with Espresso Build configs.
1 2 3 |
var options = new EspressoOptions (); options.setEspressoBuildConfig (new EspressoBuildConfig ().withBuildToolsVersion ("28.0")); // ... Other capabilities |
appium:showGradleLog
When this capability is set to true, then Appium server logs will also contain Espresso Gradle logs. By default, this capability is set to false.
1 2 3 |
var options = new EspressoOptions (); options.showGradleLog (); // ... Other capabilities |
Cloud-Specific Appium Capabilities
In today’s world, numerous cloud providers offer unique custom Appium capabilities that you must configure to run tests on devices hosted on their platforms. In this blog, we’ll focus on the LambdaTest cloud – an AI-powered test orchestration and execution platform that lets you perform mobile app testing using the Appium framework on a real device cloud. They provide a convenient Automation Capabilities Generator for generating all their supported capabilities, which can be customized per your needs.
Subscribe to the LambdaTest YouTube Channel and stay up to date with the latest tutorials around Selenium testing, Cypress testing, and more.
To get started with Appium for mobile automation, visit the documentation Appium testing on LambdaTest.
Let’s explore some of their frequently used Appium capabilities that will simplify running your mobile tests on their devices.
w3c
This capability, when set as true, indicates to LambdaTest that you want to use the W3C protocol for your test automation.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("w3c", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
platformName
This capability will set the platform name on which your test will run. For example, Android when you want to run on an Android device.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("platformName", "Android"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
deviceName
This capability will set the device name on which the test will get executed. For example, if you were to run your test on a Google Pixel device, you can set this capability as Pixel 6.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("deviceName", "Pixel 6"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
platformVersion
This capability will set the platform version on which you want to run your test. For example, if you want to run on the Android 12 platform, you can set this capability as 12.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("platformVersion", "12"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
app
This capability will set the LambdaTest application URL, which points to the application under the test you want to install on the target device. The format of the value for this capability is lt://< hash-id >.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("app", "lt://<unique-hash-id>"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
project
This capability sets the project name, which categorizes the test session on the LambdaTest platform.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("project", "Project Name"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
build
This capability sets the build name, which categorizes the test session on the LambdaTest platform under the project name.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("build", "Build Name"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
name
This capability sets the test execution session name, which gets categorized under the project and build names that are set by the earlier capabilities.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("name", "Test Name"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
devicelog
This capability, when set to true, will enable device-specific logs capturing, which you can view on the LamdaTest dashboard once the test execution is completed.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("devicelog", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
visual
This capability, when set to true, will capture screenshots on each step of the test execution, which you can view on the LambdaTest dashboard.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("visual", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
network
This capability, when set to true, will enable capturing network calls happening from the application under test, which you can view on the LambdaTest dashboard once the test execution has been completed.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("network", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
video
This capability when set to true, will enable capturing video recording of your test execution which can be viewed on the dashboard once the test execution has completed.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("video", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
deviceOrientation
This capability can be used to set the device orientation for the test session. Possible values which can be used for this capability are:
- portrait
- landscape
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("deviceOrientation", "portrait"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
geoLocation
This capability can be used to set the geographical location of the device under test to whatever country in the world. You can provide ISO country code alpha 2 code. You can learn more about it through this blog on GPS Geolocation vs IP Geolocation.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("geoLocation", "AU"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
location
This capability can be used to set the exact location of the device under test. You can provide the latitude and longitude to set the device location. You can learn more about it through this blog on Geolocation testing.
1 2 3 4 5 6 7 8 9 10 11 12 |
var locationObj = new HashMap <String, String> (); locationObj.put ("lat", "100"); locationObj.put ("long", "100"); var ltOptions = new HashMap <String, Object> (); ltOptions.put ("location", locationObj); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
isRealMobile
You can set this capability to true if you want to run on a real cloud device.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("isRealMobile", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
Test your mobile apps on real Android and iOS devices. Try LambdaTest Today!
autoGrantPermissions
You can set this capability to true, then it will automatically grant permissions to all the permissions required by the application under test.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("autoGrantPermissions", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
autoAcceptAlerts
You can set this capability to true, then it will automatically accept the alert pop-ups which may occur in the application under test.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("autoAcceptAlerts", true); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
idleTimeout
You can set this capability to an integer to set the idle timeout in seconds. LambdaTest will wait for this idle timeout before canceling a test session if there is no activity happening in that session.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("idleTimeout", 30); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
queueTimeout
You can set this capability to an integer to set the queue timeout in seconds. LambdaTest will wait for this idle timeout before canceling a test session in the queue but not getting executed until the timeout occurs.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("queueTimeout", 30); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
language
You can set the language to any other language for the application under test. You can provide ISO language code of 2 char code.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("language", "en"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
locale
You can set the locale for the application under test.
1 2 3 4 5 6 7 |
var ltOptions = new HashMap <String, Object> (); ltOptions.put ("locale", "en"); // ... Other capabilities var options = new UiAutomator2Options (); options.setCapability ("lt:options", ltOptions); |
Note: Boost your efficiency by ultimate guide of Appium Commands Cheat Sheet for Developers.
That’s a wrap!
I would like to thank you for reading here. I tried my best to cover all the useful capabilities you can use in your daily work while working with Appium.
I hope this blog on Appium capabilities helps you improve while performing Appium automation and gain more knowledge and confidence so you know exactly why you use a particular capability in your Appium test.
If you liked the blog on desired capabilities in Appium, share it with your friends so they can also benefit from it and know what capabilities Appium supports.
We have compiled all Appium Interview Questions for you. Feel free to visit it. Check it out now!
Frequently Asked Questions (FAQs)
What are Appium capabilities?
Appium capabilities, also known as desired capabilities, are a set of key-value pairs that define various parameters and settings used to configure and customize the behavior of the Appium server and the mobile application during test automation. These capabilities act as instructions to the Appium server, specifying the device platform, automation-related settings, app information, and other configurations required to interact with the mobile application effectively.
What is an example of desired capabilities in Appium?
DesiredCapabilities empower users to manage the session requests with the server, enabling them to specify their preferences. For instance, if an iOS session is desired, the Capability “PlatformName = iOS” can be set, and for an Android session, the Capability “PlatformName = Android” can be configured.
Got Questions? Drop them on LambdaTest Community. Visit now