In the past I have used Jenkins as my primary continuous integration tool. It works for Android development, but I would never describe using it as a great experience. Jenkins has seemingly unlimited flexibility, at the cost of taking significant time to wire up the common tasks. It also has one of the worst UIs I have ever used.

I recently tried out TravisCI and found it much more pleasant. Travis doesn’t seem to be as configurable as Jenkins, but the main uses cases are much simpler to setup. The UI is also much cleaner. Hosted TravisCI is free for open source projects, and there are a few price tiers for commercial projects.

TL;DR

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

language: android
jdk: oraclejdk7
env:
  global:
    - TERM=dumb
  matrix:
    - ANDROID_TARGET=android-19 ANDROID_ABI=armeabi-v7a

sdk_components:
  - build-tools-19.0.3


before_script:
  - echo no | android create avd --force -n test -t $ANDROID_TARGET --abi $ANDROID_ABI
  - emulator -avd test -no-skin -no-audio -no-window &
  - adb wait-for-device
  - adb shell input keyevent 82 &


script: ./gradlew build connectedAndroidTest

More Detail

The before_script section for launching the Android emulator was based on the setup in the Android TDD example application by Paul Estrada. The sdk_components block is a bit difference than what is commonly shown on the web for Android (including in the official documentation as of this writing). There is a TravisCI linting tool for testing configurations, and it warns for the more typical android configuration. Note that TERM=dumb is necessary to have clean Gradle log output.

There are a few assumed pre-conditions. Obviously the project is using Gradle, and specifically the Gradle wrapper. I always find using the wrapper rather than the system Gradle makes configuring the build much simpler. I also typically have Jake Wharton’s SDK Manager Plugin in the build, but that is not strictly necessary if you are only depending on the latest platform version. TravisCI will include the latest platform by default when the language is set to android.

I generally prefer a rapid feedback loop over all else when it comes to CI, including perhaps comprehensive testing of devices & flavors. By default TravisCI runs on every commit to every branch, which really helps catch mistakes early. Although TravisCI can run multiple emulators, I use only 1 to keep the build as short as possible. I also generally run the tests against one specific build variant rather than all variants as shown above. That cuts the build time significantly.

From Here

• See the TravisCI Android official documentation, which is slightly out of date but covers more advanced functionality such as running a matrix of emulators
• I love having a live build status image out of the box.
• Saving artifacts (test reports, apks, proguard mapping files) is a bit less robust than Jenkins, but pushing files to S3 is a simple option.
• Setting up notifications (email, irc, hipchat, etc) is straightforward
• TravisCI has a great setup for injecting secure environment variables in the build (APK signing key, api keys, etc)