Sencha Inc. | HTML5 Apps


EventRecorder for Android Web Applications

March 07, 2011 | Helder Correia

After we came up with RemoteJS, we started thinking about how we could go one step further regarding the testing of Android web applications based on Sencha Touch. With Monkey, it has been possible to build a test framework on top of it, but one still needs to generate the events for playing back. Also, its features are limited and it often isn’t so stable, according to our experience.

We thought the situation could be improved, not just for our own benefit by improving Sencha Touch, but also for the rest of the Sencha and Android web application communities. This is why we have created a test suite called EventRecorder that is now available on Sencha Labs. We have tested it on Froyo, Gingerbread and Honeycomb. Take a look at the video below to see a demo of the tool in action.

How it works

So, what exactly will this do for you? The suite allows you to record test cases for web applications, meaning that all user interaction with a web page will be recorded. This includes URL loads, touch events and hardware keyboard events. You can also evaluate JavaScript and capture screenshots, and the result of these actions will be saved on the host computer and can later be compared to a previous test run.

EventRecorder consists of a Python script running on a host that records all touch and hardware keyboard events, as well as allowing the user to perform a few actions described below. In addition, there’s a Java application running on your target Android device. The device application uses an Android WebView component that is able to record and replay all user interaction. This component is the exact same one used in the Android browser. The Python script communicates with this application via messages or file sending over ADB. If you’re familiar with our RemoteJS tool, you’ll have a better understanding on how it works already, since we used the same techniques for this suite.


The first thing you’ll want to do when using this tool is to record a test case. To do this you need to have an Android device connected to your computer and a working ADB setup. A PIL installation for your Python interpreter is required in order to make screen captures.


Run the script and pass a name for your test case as the argument.

python picker

The recorder will then install and run the Java application on your device and present you a prompt where you can enter commands.

URL loading

The first command will always be an URL load, which should be your target web application, e.g.

All commands starting with either http:// or www. will be interpreted as URL loads.

Text Input

After the page has been fully loaded you can start user interaction including touch and hardware keyboard events. Due to technical limitations it’s not possible to record events from the soft keyboard. If your device doesn’t have a hardware keyboard then you can use the text (or simply t) command to input test.

t Hello World

Of course you can also do this even if you have a hardware keyboard but just want the ease of inputing text from the host computer. In the particular case of testing our Sencha Touch picker example it probably doesn’t make much sense to use this functionality. However, it might definitely be very useful on examples like forms.

Screen Capture

After you’ve been navigating for a while you might want to make screen captures for later comparison. This is achieved with the screen command, or more simply


JavaScript Evaluation and Logging

Any commands not starting with any of the prefixes mentioned above will be interpreted as JavaScript. This way, entering


will cause the document title to be displayed in a popup box.

If you wish to compare JavaScript output across replays then you can use the console.log() method and the evaluated result will later be sent back to your host machine. In the code below, we log the value stored by the date picker component in the example provided in Sencha Touch.


You can of course use more complex JavaScript, but you are restricted to about 1kB of data in addition to having all JavaScript statements on one line.


When you’re done recording you simply need to press ENTER on the prompt, this will cause the recorder to stop recording and write a replay script to your current directory. The name of the script is the same name as you passed as an argument to the recorder, but with a .py extension. Please do note that the recorder will not fetch any screen capture or JavaScript log files. This is done on playback only by the replay script, which means you’ll have to play the test back once after recording to generate a baseline result set.


When you’re ready to replay you can start the script written by the recorder by running


This will replay all the URL loads, events, screen captures and JavaScript evaluations that were recorded in the previous step. Just before exiting, all screen captures and console log files will be written to your current directory.


Sencha Labs EventRecorder for Android mobile devices

Now that you have a set of result files, what should you do? Well, that depends on your requirements. Comparing the JavaScript output file (console.log) should be fairly straightforward but comparing images is a bit more tricky. For convenience, we do include a very simple application that accepts two input images and a third argument being the file name for a grayscale difference image. The output file is not written at all if the input images are identical. If you need a more complete comparison solution then you could use the compare tool from ImageMagick.

Take the picker example as an use case. We perform some events, we log the data stored by the date picker component in a text file, and we grab a screen shot. If we wish to perform a regression test, what we’re looking for is making sure that the returned date is always the same, as well as the captures being pixel-identical. In this case it would be trivial to do a comparison of both the console.log() output and the screen capture images by using any widely available third-party {“diff”:}-like tool.

Known Issues

Even though the timings of the touch events are recorded, the playback might not replay the events exactly at the point they were recorded at. Due to the overhead of the rest of the system, this is more apparent on the Android Emulator than on an actual device. Thus, the playback might not produce exactly the same result as the recording. This mostly affects fling scrolling. If you encounter cases where this gives you problems then you might have to re-record the test case.

Unfortunately, events recorded through soft keyboard typing won’t be reproduced in the playback. This is an Android limitation. As a workaround, we provide the text command described above.

Multi-touch is not yet supported, as the necessary Android API that makes that possible is only available in Gingerbread. For that reason, we decided to leave the feature out for now.


With the help of EventRecorder, we can create an entire infrastructure to automate the testing of all Sencha Touch examples, before every release and across the different devices, making sure we provide a framework with the best quality possible. It is also our hope that it can help you delivering your Android web applications in the same way. For some more information on EventRecorder, please refer to the README file.

Just like all the other tools on Sencha Labs, the entire source code of the suite is completely available under the MIT license. As usual, we appreciate your feedback and encourage you to contribute fixes and/or new features. We hope this tool can be useful in your professional or hobbyist work.

There are 6 responses. Add yours.

Jay Robinson Sencha Employee

4 years ago

Great work, WebKit team!

Jay Garcia

4 years ago

I’m excited about this.


4 years ago

Awesome stuff!


4 years ago

Hi, I’ve tried the sample code from the web site(
But, when I execute the “”, I have failed installing apk file.
The error msg was “Device tool installation failed - file xxxx is not a valid zip file”.
Do you have any idea?


4 years ago

I am testing the sample code with “python 2.7” + “pyreadline-1.6.2.win32.exe” on Windows XP.
when decode the binary string(_g_base64Apk), the result file was invalid zip file.
So, I could get valid apk file from my java code successfully and I installed the apk file.

Dan Boyle

4 years ago

Any updates, yo? How’s it coming?

Comments are Gravatar enabled. Your email address will not be shown.

Commenting is not available in this channel entry.