The example from this article was written using an Android Virtual Device with the system image R API level 30 ABI x86 target Android 11 (Google Play). You can use any image with Android 4.3 (API level 18) or higher and adapt the code according to its UI.

UI Automator

UI Automator is an Android testing framework that allows us to write scripts that can interact to any application installed in the device. UI Automator doesn’t require having access to the application source code to work. Because of that, the script can navigate and interact with the application tray, Settings application, third party applications or any other app you want to.

Creating the project

Create a new Project on Android Studio with no activity and minimum SDK 18 or higher. The Android Studio will create three different source sets in the project: main, androidTest and test. This is the default project structure in which main contains the application code, the test contains the unit tests that runs on the development machine and androidTest that is were the instrumented tests, like UI Automator ones, go by default.

If you are writing you scripts in the same project of your application, then you can just create your scripts inside androidTest directory, but in this article we are creating a project with UI Automator scripts only, to test another application which we don’t have access to its source code, so we will make some changes before starting it.

Open the build.gradle of the app module and add the following code inside android block:

This will change the directory of our instrumented tests to the maindirectory. Now you can delete both test and androidTest source sets. Also delete some resources that will no longer be used:

app/src/main/res/values/themes.xml
app/src/main/res/values-night/themes.xml
app/src/main/res/values/colors.xml

With our source sets configured, let’s add the required dependencies. Once our scripts are part of the main source set, we need to add the dependencies using implementation instead of androidTestImplementation. Also you can remove dependencies that will not be used:

After the change this is how your build.gradle will look like:

We are almost done configuring the project, we just need to modify the AndroidManifest.xml in order to remove reference to the deleted files and add the instrumentation. Open the manifest file and remove the themeatribute from application tag once we deleted theme XML files previously.

Once we are creating the scripts in the main source set, we need to manually add the instrumentation tag to the manifest files. Add the instrumentation inside the manifest tag with the name and targetPackageattributes. The name must be defined as androidx.test.runner.AndroidJUnitRunner and the targetPackage must be the same package of your application (which is com.paceli.wifitest, in this example).

You can see the AndroidManifest.xml with the changes below:

Writing our script

Having created and configured the project, we are good to proceed creating our first script. Create a new class and add the annotation @RunWith(AndroidJUnit4::class) in order to define AndroidJUnit4 as the test runner.

As usual in JUnit, the test methods must be annotated with @Test. Set up and tear down methods must be annotated with @Before and @Afterrespectively. For those who are not familiar with this approach, the code below shows the order that the methods are executed:

Running this example will produce the following logcat output:

Before Class
Before
Test
After
After Class

So let’s create a method named validateWifi in out test class and annotate it with @Test. In order to click on buttons, read text from screen, perform swipe gestures, and any other interaction with the UI, we need to get an instance of the UiDevice class. To achieve that, we declared a property to the class and added the init block with the code to get an instance. This is how our class is looking at this moment:

To interact with the elements from the screen, we need to get a reference to them using the UiDevice instance. To do that, we will call the method findObject passing the properties of the element we want to interact with. Some properties, like the text, are visible to the user, but there are several others that we cannot see on the device screen, so we need to dump the screen using the UI Automator Viewer tool that is available in the Android SDK at $ANDROID_HOME/tools/bin/uiautomatorviewer.

By clicking on the Device Screenshot button on the top left, the tool will show a screenshot and the dump of the screen currently displayed from the device connected to ADB. The elements can be chosen by clicking on them at the screenshot or at hierarchy view on the right side. Properties like index, text, content-desc, enabled, etc. are displayed in the Node detailview and.

The UiObject2 class represents the elements from screen and an instance of it is returned by the findObject method. In order to launch the Settings app, the user need to perform a scroll gesture on home screen to launch the applications list, and then click on Settings icon. So we obtained an instance of UiObject2 representing the workspace and another one for the Settings icon in the apps list screen, and then call the methods scroll and click respectively.