Tips to use Travis on an Android environment

Testing is a very important part of product development and can quickly become overwhelming. At Kuzzle we use Travis as a continuous integration tool.
Travis is a free service that can be linked to any GitHub repository, automatically running some tests on a commit to validate the testing process. It can sometimes be hard to configure especially in an Android context where you need an emulator to run an instrumentation test. Here is our experience so far with Android and Travis integration.

At Kuzzle we are very concerned about code quality . Therefore we extensively test our features.

Not to wane (we don’t even want to think about it) we run all our tests on Travis CI. We also use Codecov to measure our coverage to ensure we don’t leave anything behind.

So, how do we manage to automatically test any Android code on Travis?

First let’s see how unit and instrumentation tests are managed in a classic Android project:
– src/test/java – Here we undergo unit tests
– src/androidTest – Here we undergo instrumentation tests

What is the difference?

  • Simple unit tests are executed on your local machine on a JVM: Use these tests if you don’t need any Android context.
  • Instrumental tests are used if you want to execute your tests into an Android emulator to get an Android context such as the Context class, SharedPreference etc..

You can learn more about Android tests here.


As usual everything with Travis starts with a travis.yml configuration file.

language: android


Pretty obvious..

    - oraclejdk7

Here we can tell Travis which jdk we want to use for our local tests.


        - tools
        - build-tools-23.0.1
        - platform-tools
        - android-23

One important part of the configuration process is the dependencies that Travis use to execute our Android unit tests.
It includes the Build Tools and the Android SDK to be used.

One major thing to know is that Travis downloads an android.jar SDK according to the version you have set into the configuration file. It is a STUB of SDK where the methods throw an exception when called!
For example if you use any Log.* methods then you get an exception saying that you didn’t mock this method.
This is very frustrating because we use org.json.JSONObject from Android SDK, which is stubbed as well.  We really don’t want to mock it as it is a very important part of Android Kuzzle SDK.
The solution selected here is to use org.json.JSONObject from the jar file which we downloaded, not stubbed and  for tests dependencies only.


dependencies {
    testCompile files('libs-test/json-20140107.jar')
    bash gradlew test jacocoTestReport

Travis runs the commands under script. Here we use Gradle to run the tests and to generate our coverage with JaCoCo library.


    - bash <(curl -s

Then we send our coverage to Codecov ensuring us that it didn’t get any lower.


To run instrumentation tests into Travis. First, we need to configure it to tell him to launch an emulator and to select the right one.


    - build-tools-22.0.1
    - android-22
    - extra
    - addon
    - sys-img-armeabi-v7a-android-22
  - echo no | android create avd --force -n test -t android-22 --abi armeabi-v7a
  - emulator -avd test -no-skin -no-audio -no-window &
  - android-wait-for-emulator
  - adb shell input keyevent 82 &
    - ./gradlew connectedAndroidTest


Here we use an android-22 image. Travis doesn’t support all Android versions. You can find more at:

In the before_script section created, launch our AVD and use a Travis script located in /usr/local/bin/android-wait-for-emulator. Then wait for the emulator to be started.


Integration of Android tests under Travis is quite simple if you follow these steps.
Make sure to use the right version of your Android SDK and Build Tools according to your build.gradle.
Also keep in mind that Travis for Android is currently in beta :) />


Kevin Blondel

Related posts