Understanding Appium Desired Capabilities

Appium Desired Capabilities

Appium Desired Capabilities help us to configure the Appium server and provide the criteria which we wish to use for running our automation script. For example, we can request the environment (emulator or real-device), which version of the operating system to run the test on, and more. Desired capabilities are key/value pairs encoded in JSON format and are sent to the Appium Server by the Appium client when a new automation session is requested.

In this article, we will take a deep dive into this feature. Previously, we introduced you to Appium Desired Capabilities. This is a core capability of Appium, and if you missed it, you should also go back and review.

Figure-1:Appium Architecture.

Desired capabilities is a predefined library and in order to use it you need to import:

Org.openqa.selenium.remote.DesiredCapabilities

As Appium supports both Android and iOS, There are separate capabilities for both. However most of the capabilities remain common to both platforms.

Android:

{
 "platformName": "Android",
 "platformVersion": "8.0",
 "app": "/Users/username/Downloads/sample.apk",
 "deviceName": "c4e3f3cda"
 "automationName": "UiAutomator2"
}

IOS:

{
 "platformName": "iOS",
 "platformVersion": "11.4.1",
 "app": "/path/to/.ipa/file",
 "deviceName": "John’s iPhone",
 "udid": "bea36e2b0262ae4b77bd3463bd462922ee935d24"
 "automationName": "XCUITest"
}

The above is the JSON representation. To use this in code, you can define the desired capabilities (for Android) as below:

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability("platformName", "Android");
dc.setCapability("platformVersion", "8.0");
dc.setCapability("app", "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");
dc.setCapability("deviceName", "c4e3f3cd");
dc.setCapability("automationName", "UiAutomator2");

In the above code snippet instead of defining capability name in a string you can use the Appium predefined interfaces such as MobileCapabilityType, IOSMobileCapabilityType and AndroidMobileCapabilityType to get capability names, so the above code snippet can be written in a better way:

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "8.0");
dc.setCapability(MobileCapabilityType.APP, "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "c4e3f3cd");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Appium Desired Capabilities for iOS and Android

We have many Appium desired capabilities at our disposal, depending on what we are trying to accomplish. However, there are specific capabilities we need to set based on what we are trying to test:

• Mobile Web Android.
• Mobile Web iOS.
• Mobile Native Android.
• Mobile Native iOS.

Mobile web – Android

If you want to automate the Chrome browser on Android device, then you need to use these Desired Capabilities.

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
// This capability will open the Chrome browser instead of Native app.
dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.CHROME);
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Mobile web – iOS

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
// This capability will open the Safari browser instead of Native app.
dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.SAFARI);
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");
// If you are using Real iPhone device then you need to specify "udid" of device.
dc.setCapability("udid", "UDID of your test device");

Mobile native – Android

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.APP, "/path/to/.apk/file");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Mobile native – iOS

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.APP, "/path/to/.app or .ipa/file");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");

There are many, many capabilities that Appium supports. We can categorize the capabilities into 3 parts:

• General Capabilities.
• iOS Capabilities.
• Android Capabilities.

While you clearly don’t need to memorize all of these, we do suggest you spend the time to familiarize yourself with these capabilities. As you use Appium more and more and continue to consult this list, you will eventually have a good sense of what capabilities are available to you.

General Capabilities

Android Capabilities

These capabilities are available only on Android-based drivers (like UiAutomator2 for example).

iOS Capabilities

These capabilities are available only on the XCUITest Driver and the deprecated UIAutomation Driver.

Important Capabilities

Reset strategies

In Mobile Application Automation, most of the execution time is spent on Application installation. Sometimes, you do not want to reinstall the application (like between tests). In this case, Appium has provided 2 capabilities named noReset and fullReset, which provides control over application installation where you can leverage the right combination of the two flags.

NOTE: You can know more about Appium Capabilities on Official Appium Docs periodically: appium.

The following additional capabilities are reprinted with permission from Jonathan Lipps, Founding Principal of Cloud Grey, a mobile testing services company. Refer to footnote for the source link.

Android-specific Capabilities

1. disableAndroidWatchers: The only way to check for toast messages on Android is for the Appium UiAutomator2 driver to run a loop, constantly checking the state of the device. Running a loop like this takes up valuable CPU cycles and has been observed to make scrolling less consistent, for example. If you don’t need the features that require the watcher loop (like toast verification), then set this cap to true to turn it off entirely and save your device some cycles.
2. autoGrantPermission: Set to true to have Appium attempt to automatically determine your app permissions and grant them. For example, to avoid system pop ups asking for permission later on in the test.
3. skipUnlock: Appium doesn’t assume that your device is unlocked, and it should be to successfully run tests. So, it installs and runs a little helper app that tries to unlock the screen before a test. Sometimes this works, and sometimes this doesn’t. But that’s beside the point: either way, it takes time! If you know your screen is unlocked, because you’re managing screen state with something other than Appium, tell Appium not to bother with this little startup routine and save yourself a second or three, by setting this cap to true.
4. appWaitPackage and appWaitActivity: Android activities can be kind of funny. In many apps, the activity used to launch the app is not the same as the activity, which is active when the user initially interacts with the application. Typically, it’s this latter activity you care about when you run an Appium test. You want to make sure that Appium doesn’t consider the session started until this activity is active, regardless of what happened to the launch activity. In this scenario, you need to tell Appium to wait for the correct activity, since the one it automatically retrieves from your app manifest will be the launch activity. You can use the appWaitPackage and appWaitActivity to tell Appium to consider a session started (and hence return control to your test code) only when the package and activity specified have become active. This can greatly help the stability of session start, because your test code can assume your app is on the activity expects when the session starts.
5. ignoreUnimportantViews: Android has two modes for expressing its layout hierarchy: normal and “compressed”. The compressed layout hierarchy is a subset of the hierarchy that the OS itself sees, restricted to elements which the OS thinks are more relevant for users. For example, elements with accessibility information set on them. Because compressed mode generates a smaller XML file, and perhaps for other Android-internal reasons, it’s often faster to get the hierarchy in compressed mode. If you’re running into page source queries taking a very long time, you might try setting this cap to true.

Note that the XML returned in the different modes is … different. This means that XPath queries that worked in one mode will likely not work in the other. Make sure you don’t change this back and forth if you rely on XPath!

iOS-specific Capabilities

1. usePrebuiltWDA and derivedDataPath: Typically, Appium uses xcodebuild under the hood to both build WebDriverAgent and kick off the XCUITest process that powers the test session. If you have a prebuilt WebDriverAgent binary and would like to save some time on startup, set the usePrebuiltWDA cap to true. This cap could be used in conjunction with derivedDataPath, which is the path to the derived data folder where your WebDriverAgent binary is dumped by Xcode.
2. useJSONSource: For large applications, it can be faster for Appium to deal with the app hierarchy internally as JSON, rather than XML, and convert it to XML at the “edge”, so to speak—in the Appium driver itself, rather than lower in the stack. Basically, give this a try if getting the iOS app source is taking forever.
3. iosInstallPause: Sometimes, large iOS applications can take a while to launch, but there’s no way for Appium to automatically detect when an app is ready for use or not. If you have such an app, set this cap to the number of milliseconds you’d like Appium to wait after WebDriverAgent thinks the app is online, before Appium hands back control to your test script. It might help make session startup a bit more stable.
4. maxTypingFrequency: If you notice errors during typing, for example the wrong keys being pressed or visual oddities you notice while watching a test, try slowing the typing down. Set this cap to an integer and play around with the value until things work. Lower is slower, higher is faster! The default is 60.
5. realDeviceScreenshotter: Appium has its own methods for capturing screenshots from simulators and devices, but especially on real devices this can be slow and/or flaky. If you’re a fan of the libimobiledevice suite and happen to have idevicescreenshot on your system, you can use this cap to let Appium know you’d prefer to retrieve the screenshot via a call to that binary instead of using its own internal methods. To make it happen, simply set this cap to the string “idevicescreenshot”!
6. simpleIsVisibleCheck: Element visibility checks in XCUITest are fraught with flakiness and complexity. By default, the visibility checks available don’t always do a great job. Appium implemented another type of visibility check inside of WebDriverAgent that might be more reliable for your app, though, it comes with the downside that the checks could take longer for some apps. As with many things in life, we sometimes have to make trade-offs between speed and reliability.

We suggest reviewing these capabilities and familiarizing yourself with them. It isn’t necessary to memorize them, but as you get more sophisticated testing needs, it will be good to keep coming back here to see which one will do the trick. We’ll be using various forms of these capabilities throughout these Appium articles, so you will start getting more familiar with them as we work through more examples.