A Complete Tutorial to Appium Capabilities for Mobile Automation

Capabilities are a set of parameters that describe 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, 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, like Android, have their own set of capabilities, and iOS has its own.
• Driver-specific Appium capabilities, 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.

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 that lists all the option classes along with their corresponding platform and automation name values, which are automatically set when you use the option class:

For example, in the following code snippet, when we initialize the UiAutomator2Options options class, the platformName, and appium:automationName capabilities will be set to Android and UiAutomator2 respectively.

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:

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.

var options = new UiAutomator2Options ();

options.withBrowserName (Browser.CHROME.browserName ());

// ... Other capabilities

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.

var options = new UiAutomator2Options ();

options.withBrowserName (Browser.CHROME.browserName ());

// ... 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.

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.

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 was created due to the previous executions, including the applications that 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.

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.

var options = new UiAutomator2Options ();

options.setEventTimings (true);

// ... Other capabilities

Once this capability is enabled, you can get event details using the following code example:

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.

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.

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.

var options = new UiAutomator2Options ();

options.setCapability ("appium:settings[ignoreUnimportantViews]", true);

// ... Other capabilities

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.

var options = new UiAutomator2Options ();

options.setCapability ("appium:settings[ignoreUnimportantViews]", true);

// ... 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.

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.

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.

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.

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.

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, 60 seconds is set for this capability. This capability is not supported by the Android Espresso driver.

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.

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.

var options = new UiAutomator2Options ();

options.setMjpegServerPort (9200);

// ... 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.

var options = new UiAutomator2Options ();

options.skipServerInstallation ();

// ... Other capabilities

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.

var options = new UiAutomator2Options ();

options.setAppPackage ("packageName");

// ... Other capabilities

appium:appActivity

Appium will try to launch the application activity that matches the provided capability. If not provided, Appium will automatically identify the main activity from the appium:app capability.

var options = new UiAutomator2Options ();

options.setAppPackage ("packageName");

// ... 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.

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.

var options = new UiAutomator2Options ();

options.setAppWaitPackage ("packageName");

// ... Other capabilities

appium:appWaitDuration

The wait timeout is in milliseconds for which Appium should wait until the application under test gets launched. By default, 20000 ms is used.

var options = new UiAutomator2Options ();

options.setAppWaitPackage ("packageName");

// ... 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.

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 that the application under test may request when it is first installed and launched; otherwise, you will see the permissions pop-up whenever the application under test starts for the first time. By default, this is set as false.

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.

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.

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.

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.

var options = new UiAutomator2Options ();

options.setAdbPort (8400);

// ... Other capabilities

appium:remoteAdbHost

This is the host address on which ADB will be running.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

final var chromeOptions = new ChromeOptions ();

chromeOptions.setBinary ("/path/to/chrome/exe");

 

 

var options = new UiAutomator2Options ();

options.setChromeOptions (chromeOptions.asMap ());

// ... 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 that is entered using a key event

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.

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.

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.

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.

var options = new UiAutomator2Options ();

options.disableWindowAnimation ();

// ... Other capabilities

The 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.

var options = new UiAutomator2Options ();

options.disableWindowAnimation ();

// ... 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.

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.

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.

var options = new XCUITestOptions ();

options.setCapability (IOSMobileCapabilityType.XCODE_SIGNING_ID, "iPhone Developer");

// ... 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.

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.

var options = new XCUITestOptions ();

options.setWdaLaunchTimeout (Duration.ofSeconds (30));

// ... Other capabilities

appium:wdaConnectionTimeout

This is the timeout in milliseconds in which Appium will wait for the response from WebDriverAgent to respond. By default, 240000 ms is used.

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.

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.

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.

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.

var options = new XCUITestOptions ();

options.setWdaLocalPort (8102);

// ... 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.

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.

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.

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:

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.

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.

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.

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:

var options = new XCUITestOptions ();

options.simulatorTracePointer ();

// ... Other capabilities

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.

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.

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: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.

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 times in milliseconds Appium will wait for the UiAutomator2 server to launch on the device. By default, this capability is set as 30000 ms.

var options = new XCUITestOptions ();

options.clearSystemFiles ();

// ... Other capabilities

appium:uiautomator2ServerInstallTimeout

This is the maximum number of times 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.

var options = new UiAutomator2Options ();

options.setUiautomator2ServerInstallTimeout (Duration.ofSeconds (30));

// ... Other capabilities

appium:uiautomator2ServerReadTimeout

This is the maximum number of times in milliseconds Appium will wait for an HTTP response to come from the UiAutomator2 server, which is installed on the target device. By default, this value is set as 240000 ms.

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.

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.

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.

var options = new UiAutomator2Options ();

options.setCapability (AndroidMobileCapabilityType.AUTO_LAUNCH, true);

// ... 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.

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.

ar 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.

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.