Category: Android


Travis CI for Android

I’m currently contributing to BiteMoi to teach myself some Android. When we kicked off the project we started with a Continuous Integration spike and Travis CI was the winner. Travis CI is a free hosted Continuous Integration platform for the Open Source community. This tutorial will get you up and running with the Maven Android quickstart project and Travis CI.

Prerequisites:

  • Maven (>= 3.0.3)
  • Android SDK

What is the plan?

The objective here is to hook up a skeleton Maven Android project (hosted on GitHub) to Travis CI. We will then configure Travis CI to build our project when we push code changes.

The BiteMoi project grew from Android Maven quickstart skeleton code. If you want to generate your own project you can use the android-maven-plugin using the android-quickstart-archetype by doing something like the following:

$ mvn archetype:generate -DarchetypeArtifactId=android-quickstart -DarchetypeGroupId=de.akquinet.android.archetypes -DarchetypeVersion=1.0.8 -DgroupId=com.codenes -DartifactId=my-android-application -Dplatform=16

At this point, if you’re using your own Maven quickstart project you should be able to build it by executing the Maven install goal on the command line:

$ mvn install

Maven will try to download the internets but be patient, it won’t happen every time. If you created your own project, it’s time to host it on GitHub.

It’s time for introductions

To introduce your project to Travis CI you will need to create a file called .travis.yml in the project root directory. This file basically contains a bunch of commands that instructs Travis CI how to build your project. Paste the following into your .travis.yml file:

language: java
jdk: oraclejdk7
before_install:
- sudo apt-get update -qq
- if [ `uname -m` = x86_64 ]; then sudo apt-get install -qq --force-yes libgd2-xpm ia32-libs ia32-libs-multiarch; fi
- wget http://dl.google.com/android/android-sdk_r21.0.1-linux.tgz
- tar -xzf android-sdk_r21.0.1-linux.tgz
- export ANDROID_HOME=~/build/BiteMoi/BiteMeAndroid/android-sdk-linux
- export PATH=${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/platform-tools
- android update sdk --filter platform-tools,android-16,extra-android-support,android-17,sysimg-17 --no-ui --force

The commands we pasted are basically telling Travis CI to do the following:

  1. Spin up a Vagrant VM suitable for Java development
  2. Use Oracle JDK 7
  3. Get info about the latest packages available to me
  4. The Travis VM has a 64 bit OS but I need to install a lib that will allow me to run 32 bit Android SDK on it
  5. Download the Android SDK r21.0.1 Linux distro
  6. Explode the Android SDK distro
  7. Setup my ANDROID_HOME environment variable
  8. Put Android tools and platform-tools on my PATH
  9. Download Android platform 16 (we don’t want all platforms as we have limited space in the Travis CI environment)

Add the new file to Git in your root project directory and commit your project.

Travis CI Configuration

  1. Create a Travis CI account (you can sign in with GitHub)
  2. Navigate to your Travis Profile page
  3. Select and copy your Travis CI token

GitHub Configuration

  1. Navigate to your project on GitHub
  2. Select Settings
  3. Select Service Hooks
  4. Under the Available Service Hooks section select Travis
  5. Under User enter your Travis CI username
  6. Under Token paste your Travis CI token
  7. Check the Active checkbox
  8. Press the Update Settings button
  9. To trigger a Travis CI build from GitHub press the Test Hook button

When I first did this it took AGES for Travis CI to pick up my build. Do not despair. You can help things along by enabling the service hook via your Travis CI Profile page. Navigate to your project repository and turn on the Travis service hook for your project. Sometimes the Travis CI job queue is so big that your job will take a while to get to the top of the queue. This is really annoying as you won’t get instant feedback about your commit and you will have to wait a while to discover if you broke the build in the CI environment.

Travis CI Build

At this point you should have a successful build in Travis CI. See the console output here for the equivalent BiteMoi first green build (note the project has since been forked). By default, Travis picks up that we have a Maven project and executes the Maven install goal for us so we don’t need to put it in our .travis.yml file unless we want to execute a different goal.

Troubleshooting

It’s more than possible you don’t have a green build, to debug it you have a couple of options.

Basic

Inspect the Travis CI build console output and depending on what your error message is, try putting some basic debugging statements into your .travis.yml file e.g.

before_install:
- pwd // Print current working directory
- echo $PATH // Check your PATH environment variable
- mvn -v // What version of Maven is my Travis VM using?

And so on… You will quickly realize debugging in the Travis CI environment is a nightmare.

Better

When we develop code we want all of our environments to be as similar as possible. It is asking for trouble to develop on a Mac for example and then expect your build to work in the Travis CI (Linux) environment.

To set up a development environment that is close to the Travis CI VM we can use Vagrant and the Travis CI JVM Vagrant box to spin up our own development VM.

  1. Install Vagrant and VirtualBox
  2. Download the Travis CI JVM box (this file is ~3 gig)
  3. Add the Travis CI JVM box to Vagrant:
  4. $ vagrant box add travis-jvm /path/to/travis-jvm.box
  5. Create a directory to store your vagrant file:
  6. $ mkdir travis-dev
    $ cd travis-dev
  7. Initialise the VM:
  8. $ vagrant init travis-jvm
  9. Edit your Vagrantfile:
  10. $ vim Vagrantfile
  11. Insert the following in the Vagrant::Config.run do |config| section:
  12. config.ssh.username = "travis"
  13. Spin up the VM:
  14. $ vagrant up
  15. SSH to the VM:
  16. $ vagrant ssh

Once you SSH to your VM you are ready to Git clone your repo and start developing on your Travis development VM. Before you commit code, execute your Travis commands locally. If your builds are passing locally you can be pretty confident they will pass in the Travis CI environment.

Android Helloworld

I’m just starting to look at writing Android apps for the first time and lets just say my Helloworld experience was not ideal. Things just didn’t exactly work first go and when it did work it would suddenly stop working, then start working again and so on (see Troubleshooting for details). Not all that inspiring when all you are trying to run is Helloworld!

Preconditions

Allow me to set the scene:

Platform: Mac OS X 10.6.5 (Snow Leopard)
IDE: Eclipse
Android SDK: 2.3

I’m using Eclipse because it would seem that it has better Android support than NetBeans currently (and comes recommended by http://developer.android.com) so let’s roll with that. Being a Java developer I already had Eclipse Java EE for Web Developers – Galileo (64-bit) on my machine so I am using that. Check http://developer.android.com/sdk/requirements.html to see if your version of Eclipse is compatible before proceeding.

Setup

I will try and gloss over the setup instructions for Android dev since you can find them in great detail online already. In brief:

  1. Download the Android SDK http://developer.android.com/sdk/index.html and extract (avoid white space in your path to SDK). Add/modify your PATH variable within .bash-profile (where <pathToAndroidSDK> is something like “yourInstallPath/android-sdk-mac_86″):
  2. export PATH=${PATH}:<pathToAndroidSDK>/platform-tools:<pathToAndroidSDK>/tools
  1. Install the ADP plug-in for Eclipse. In Eclipse go to¬†Help –> Install New Software… –> Work with: https://dl-ssl.google.com/android/eclipse/ –> Press Enter. Check “Developer Tools” when it appears in the list and complete the install.
  2. Open Android SDK and AVD Manager (Note. This can also be done inside Eclipse Window –> Android SDK and AVD Manager) :
  3. $ cd <pathToAndroidSDK>/tools
    $ ./android
  4. In Android SDK and AVD Manager create a new virtual device. Mine had the following custom properties:
  5. Name: Android2.3
    Target: Android 2.3 - API Level 9
  6. Once your AVD has been successfully created, start Eclipse.
  7. In Eclipse, create a new Android project File –> New Project –> Android Project. Mine had the following custom properties:
  8. Project Name: AndroidHello
    Build Target: Android 2.3
    Application Name: Hello
    Package Name: com.codenes
    Create Activity: AndroidHello
    Min SDK Version: 9
  9. Expand the newly created project in the package explorer. Under the src directory you will find AndroidHello.java. We are going to modify this file ever so slightly to present the text “Hello, Android” on application startup. Modify this file to look like the following:
  10. Save your project. Let’s try and run it. Right click on your project in the package explorer and select¬†Run As –> Android Application.
  11. You should see the emulator appear and your Eclipse console should print out some promising messages as it launches the emulator, uploads, installs and finally starts your app. I have to say that this whole process is pretty darn slow for my liking.
  12. The only notable thing at this point is the application doesn’t always start up automatically which was what I expected. It seems like it only does the first time it is loaded onto a new emulator as far as I can tell. I found that I had to hit the menu button subsequent times to launch it.
  13. Check out your app (in all it’s awesomeness) then navigate to the apps screen in the emulator to discover that it can also be launched through the icon “AndroidHello”.

Removing Your Application

  1. Start the Emulator if it is not already running.
  2. Open a terminal:
$ cd <pathToAndroidSDK>/platform-tools
$ ./adb shell
# cd data/app
# ls (to view all of the .apk apps installed on the emulator)
# rm <yourApp.apk>
# exit

Troubleshooting

  • Be careful specifying a SD card size when creating your Android Virtual Device. Initially I put some default value in this field and I was getting the following error in the Eclipse console (app killed almost immediately after startup):
  • Use LogCat to examine more meaningful error messages if you are having problems running your app. In Eclipse go to Window –> Show View –> Other –> Android –> LogCat. E.g. for the above problem with the SD card value I was seeing “Low Memory” messages in LogCat prior to processes being killed which led me to the problem.