Android Automation (101)

This is a quick overview on accomplishing Android test automation on remote devices.

First, we need to be able to interact with each of the visible objects on the screen, for that we use an open source framework named Robotium which uses the native language of the android SDK to understand what kind of views (view are objects that displayed on the screen in Android application) are visible, also it allows interaction with those views.

So now we are able to interact with objects that are currently displayed on the screen, but this easy interface comes with some heavy restrictions, in order for us to be able to use Robotium we must provide an Instrumentation object.

What is Instrumentation? This object is natively to the Java language, but in Android it has the main role of controlling the life cycle of an application. An Android application has specific life cycle that cannot be broken:

application life cycle

The instrumentation has an ability to run code before each one of these events. This ability is used to inject relevant test code and allow test automation.

Now that we sort of understand what Instrumentation is, we can get back to setting up the Robotium. In order to provide this we can use the a test case natively provided by android ActivityInstrumentationTestCase2.

Now that we have accomplished to interact with an Android application, we need to be able to connect, from the testing environment, to the Android application under test. This is a remote Android application (an .apk that runs on actual device). So what is the difference?

a)     The test code we write will be located off the device

b)     The code will have to be transferred to the device by some sort of connection

c)     The code will not run as part of the apk code, it will run separately

To be able to answer this questions, first we must understand how to re-answer our previous question, how Instrumentation is provided? We cannot use the ActivityInstrumentationTestCase2 because we now supposed to run on native java language without Android SDK.

The solution is that we have chosen is to create an apk TcpServerActivity that creates an Instrumentation that is being instanciated with the main activity of the AUT (Application under Test).  A problem rises, because the instrumentation is actually part of another application it runs under a scope of the AUT, so technically it doesn’t run under our application’s scope. To resolve this, we created a service that runs in the background, which the Instrumentation registers’ to it.

Now we can create a simple TCP server (hence the application name) that receives pre-defined commands from the user and sends them via the service to the instrumentation which translates them into the Robotium interface.

Overview of the architecture can be viewed by this design :

architectue

 Tal Ben-Shabtay