Skip to content

We’ll be continuing the topic we discussed in our last Appium blog post on finding UI elements and this is the 17th blog in our series of Things You Should Know About Appium. This time we’ll be focusing on Selendroid and how it helps to identify UI elements under Appium test execution. Just like Appium and uiautomator, Selendroid also comes with a useful inspector tool – Selendroid Inspector – which we will also take a look at in this post. And obviously, this applies only to Android.

Selendroid, which is based on Android instrumentation, is essential when targeting Android devices of API level 17 or lower (part of Android Jelly Bean, all of Ice Cream Sandwich, Gingerbread and older). Appium’s default automation is based on uiautomator libraries, which support API level 17 and higher. With this in mind, you will need to use both automation backends, if you’re targeting both lower and higher than API level 17 (=Android 4.2, 4.2.1 and 4.2.2). Download our free Appium beginner’s guide to check if you have a proper setup to successfully find UI elements with Selendroid Back End.

Screen Shot 2016-01-11 at 7.37.15 PM

Despite Selendroid being used as one option for Appium, there are lots of great features that you can utilize in your test script creation, test execution and generally in your test automation process:

  • Full compatibility with the JSON Wire Protocol
  • App under test requires no modifications or tweaks (due to nature of instrumentation)
  • Mobile web testing is also possible, even as an embedded in Android app (WebView app)
  • UI elements can be found with varying locators
  • The concept works the same for native and hybrid apps
  • In an advanced framework, gestures and other not-just-click interactions are fully supported
  • It was done for both emulators and real devices from the beginning, so even a large set of devices works fine with Selendroid
  • Quick and handy tool – Selendroid Inspector

How to Start Standalone Selendroid?

Selendroid can be executed also as a standalone. In order to get standalone Selendroid up and running, you need to first start the Selendroid-standalone component and then client driver can be instantiated.

This can be done via a shell by running the following command:

java -jar selendroid-standalone-0.17.0-with-dependencies.jar -app bitbarSelendroidSampleApp.apk

Another option is to start the Selendroid-standalone component directly from the test code:

SelendroidConfiguration config = new SelendroidConfiguration();
selendroidServer = new SelendroidLauncher(config);

You can check that the application(s) and the devices are recognized by opening a browser and navigating to http://localhost:4444/wd/hub/status.

You should see a result similar to this:

  status: 0,
  value: {
  "os": {
    "name": "Android"
  "build": {
    "browserName": "Selendroid",
    "version": "0.17.0"
  "supportedApps": [{
    "appId": "",
    "mainActivity": "",
    "basePackage": ""
  "supportedDevices": [{
    "screenSize": "1280x800",
    "targetPlatform": "ANDROID",
    "device": "Asus Memo Pad Smart 10 ME102A",
    "avdName": "latest"

Which Back End Is Used – uiautomator or Selendroid?

Our test sample illustrates one way to tackle the situation where both backends are being used as needed:

First, we use the device_API_level function in to determine the API level of our device:

apiLevel = deviceFinder.device_API_level(testdroid_device)

With the apiLevel, we can then choose the testdroid_target accordingly:

if apiLevel > 16:
   desired_capabilities_cloud['testdroid_target'] = 'Android'
   desired_capabilities_cloud['testdroid_target'] = 'Selendroid'

We also place a boolean value to true, when we find out that the capabilities include automationName cap with value Selendroid:

if 'automationName' in self.driver.capabilities:
   if self.driver.capabilities['automationName'] == 'selendroid':
      isSelendroid = True

Now we can use the isSelendroid to let the script know when to use the Selendroid specific driver command and when not to:

if isSelendroid:
   elem = self.driver.find_element_by_link_text('Buy 101 devices')
   elem = self.driver.find_element_by_name('Buy 101 devices')

As you can see, the same attribute of an element may need to use a different find_element convention. Also, Selendroid does not support resource-id attributes at all, since they were introduced on Android version 4.3 (API 18). When automating a test via Selendroid, you will need to use other element types instead.

What Is and How to Use Selendroid Inspector

It’s pretty similar to Appium Inspector and uiautomatorviewer but Selendroid also has its own inspection tool called Selendroid Inspector. Basically It’s a web app which is embedded inside Selendroid test server. Its purpose is to let you inspect the current state of your app’s UI and find elements of your app the same way as with uiautomatorviewer. If you are interested to learn more about these tools for test script generation take a look at this blog post.

Here is how to get it up and running when you have started Selendroid-standalone:

1) Start a test session.

2) Open your web browsers and navigate to http://localhost:4444/inspector.

3) That’s it! You can view the hierarchy of your app, view standalone UI elements and their properties, record clicks and some other actions, display and view the HTML source of any web view, and also use its XPath helper to get the specific XPath.

We’ll be covering XPath more in details in our upcoming blogs.

Happy Testing and stay tuned for more details in best practices with Appium and how to build yet better tests with it!


Article author