Saturday, June 2, 2012

Maven, Android, Travis-CI and More Awesome Sauce

Background

Recently I started working on an Android application for a side project.  From the beginning, one thing I wanted to accomplish was to setup continuous integration from the get-go.  After looking into it for a bit, I discovered that there were three potential options for me:
Of those three options, the only one that would allow me to test my application on an actual Android emulator was the first, and since I wanted to spend exactly $0 towards it, the latter two were more appealing.  Since I have traditionally used Jenkins in the past for my Android applications, I decided to go with a combination of Maven, the maven-android-plugin and travis-ci for this project.

I don't blog much (as you can see), but after a bit of struggle with getting this building successfully on travis-ci I decided to share my experiences with this.  I have made the example test project available on Github.

Creating the Project

Using the maven-android-plugin, I created the skeleton application using the example on android-quickstart-archetype.  Here is the command that I used for my sample project:


The only information that you need to modify from this example would be the groupId, artifactId and the platform that you are building for (note this).  This should be enough to build your project using the mvn install target.

Setting Up Travis-CI

If we add a vanilla .travis.yml file to our application, you'll notice that out of the box we will get a build failure.


Not surprisingly it is because the travis-ci build agents do not have any sort of android environment setup on them.   To get around this, we will need to take advantage of the various hooks in the build lifecycle that travis-ci provides you to setup an android environment prior to building our application.  In order to do this, we will need to do the following in our .travis.yml:
  • download the latest android SDK and unzip it
  • setup the ANDROID_HOME environment variable to point to the SDK that we downloaded
  • fix up our PATH variable to point to the tools and platform-tools directory in our SDK
  • tell our android environment to update our local SDK with the target API that we are building our application for

Choosing the Right Environment

Since travis-ci has a limited amount of space that we can take up and the full Android environment is huge, we will need to tell android to only grab the specific SDK that our application is building for.  To find this information out, you can run the android list sdk command from your terminal.  Doing so will give you a list of what is available to update.  Since we are targeting our application for API Level 10, we will want to note the package number (9).


Platform To Stand On

In addition to choosing the proper platform SDKs that your application builds for, you'll also want to be sure to include both the Android Tools and Android Platform Tools (options 1 and 2) for the SDK that you are targeting.

Robolectric

For those that haven't at least checked out Robolectric to test drive your Android applications, do yourself a favor.  I had heard about Robolectric when I first started writing Android applications, but at the time thought it would be more prudent to use the tools available through android.test.  Currently, I support a good mixture between Robolectric at the unit level and android.test at the integration level, but that is a topic for another blog post. 

Including Robolectric In Your pom.xml

Robolectric has a good quick start guide to adding it to your Maven project.  The general idea is to have entries for Robolectric and JUnit in your <dependencies /> entry of your pom.xml.  For this project, I've just added a simple test that verifies we get the proper greeting message when the application starts.  Listed below are my HelloAndroidActivityTest.java and my pom.xml.




Putting It All Together

Now that you know what API level to include and our Maven project is setup to build our test, the only thing left to do is to perform the steps needed in the before_install portion of our .travis.yml.  Here is what our resulting file looks like:


And there you have it.  After setting up the appropriate android environment in the travis-ci environment, we are now green.

Summary

Though this is a rudimentary example, I still think it is cool to see how powerful travis-ci can be.  I would also like to explore setting up some integration level tests in travis-ci using something similar to how Jenkins uses the XVNC plugin to run an emulator on a server.

6 comments:

  1. You can update JUnit to 4.10 ;)
    BTW, thanx for using Android-Archetypes

    ReplyDelete
  2. Great post, really useful for Android developers needing a CI system. One thing you mentioned is about wanting to be able to run tests on the Android emulator. I'm the co-founder of https://skyforge.io in which we're focusing on mobile development tools as a service, and our current offering is an automated service for testing Android apps on the emulator. Definitely check us out if you think that might be useful to you. We have a REST Api to hook into CI systems as well, which a few of our customers have used to hook into Jenkins/Hudson.

    ReplyDelete
  3. Looks like travis changed their directory, it's now "build" instead of "builds"

    ReplyDelete
  4. Good blog post. I expanded on this to also include integration tests running in an emulator - see my post here.

    ReplyDelete
  5. Persistent Integration (CI) empower engineers to incorporate code into a common vault a few times each day. Each registration is then confirmed by a robotized build, enabling groups to recognize issues early. I find this a very good website for the Travis CI Build Monitoring , If you want you can visit this site.

    ReplyDelete