Android Automate

code

What is it?

Android automate is an early project of mine that allows external android app ui automation for testing purposes. It is somewhat limited, and if I were to remake it, I would most likely not do it this way.

How was it made?

In the summer of 2019, I got an co-op working for Nokia as a network automation engineer as well as doing network testing. This being my first internship, I was quite excited to start. Part of my job was to make sure that network traffic was being correctly routed on mobile devices. This meant that I had to find a way to trigger network traffic on a large array of network devices in a repeatable manner. Normally, this was done manually which meant that a testing engineer would have to grab a device, and use an app to generate the network traffic. Every time an app got an update, this procedure would have to be repeated. My intern project for that summer would be to try and automate this.

At first, I assumed that existing testing frameworks such as selenium and Appium would work well for automating repeatable ui interactions for a variety of apps, however it seems that most testing frameworks assume that testing is being done by the devs of the app, and that the source code is available to insert hooks into. Given that my aim for testing was to interact with the apps externally, I had to research alternative to the standard available testing frameworks.

After looking around, I found the android debug bridge, or adb for short. This is a command line interface for linux that allows general interaction with android apps running on either an emulator, or a real phone plugged in. It allowed for the recording of touchscreen data, and for simulated playback of touch data aswell. You could query device parameters such as screen size, aswell as many other characteristics of the device. Importantly, it would also let you parse ui element nodes from the screen.

Using all of this, I made a command line interface that allowed users to generate workflows either by recording sequences of touch inputs and replaying them, or by sequentially navigating the ui of an app by parsing the ui element nodes, and allowing users to specify which one they would like to click on next. This would allow users to chain together navigation workflows to simulate user interactions completely separately of the app. To the android device, this was completely indistinguishable from a user natively inputting the gestures and touches manually.

Improvements

In retrospect, my implementation of this system was very naive. I was not yet familiar with how to use databases to store data about touch inputs and ui navigation sequences. I did not use a state machine for the CLI interface, and generally did not use good programming paradigms and design patterns. As such, it's probably not a very robust system. That being said, it was a good project and I learned a lot while doing it.