Android continuous integration – Android Maven plugin

Continuous feedback on how our changes affect the current code allow us to confidently add functionality. Documentation around testing on the Android platform continuous or otherwise is scarce so here we explain how to continuously compile your Android project’s tests in a central area for the benefit of the whole team and it’s clients.

The main components of our continuous integration system are:

Here we wish to share and document our set up and explore some capabilities of the android maven plugin. If you are brand new to it you may wish to first check out Maven in 5 minutes and maven-android-plugin’s useful Getting Started guide.

Android maven plugin helps us with the following android deployment tasks:

  • Building your App
  • Running Behaviour / Unit Tests
  • Running Instrumentations
  • Setting up your test environment
  • Signing your release
  • Optimization of .apk files via zipalign

We want to show you a real example of an application built with the help of the maven-android-plugin. It’s an Avatar Creator app for WeeWorld.

WeeMeeWeeWorld

The app is now on the market, so go ahead and check it out! (0.99$)

If you’re quite familiar with maven and the android plugin, you might want to jump straight to the Real Life Example at the end of this post and check out the full configuration.

Building your App

To buid an apk, your app first needs to cite a version of android platform as a build path dependency in your application’s pom file (as provided scope). More on dependency scope.

<dependency>
  <groupId>com.google.android</groupId>
  <artifactId>android</artifactId>
  <version>2.2.1</version>
  <scope>provided</scope>
  <type>jar</type> <!-- optional -->
</dependency>
<!--Currently valid values: 1.5_r3,1.6_r2,2.0_r1,2.0.1_r1,2.1_r1,2.2.1-->
<!--Those packages are on the maven central repository-->


The project must then reference the maven android plugin within the project’s pom along with the android API level targeted, here we cite version 2.2 (api level 8 )

<plugin>
  <groupId>com.jayway.maven.plugins.android.generation2</groupId>
  <artifactId>maven-android-plugin</artifactId>
  <configuration>
    <sdk>
      <platform>8</platform>
    </sdk>
    <deleteConflictingFiles>true</deleteConflictingFiles>
  </configuration>
  <extensions>true</extensions>
</plugin>


Reference a java compiler version, since the default source and target values are 1.3 and 1.1 respectively, and android uses annotations conforming to java 5

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.5</source>
    <target>1.5</target>
  </configuration>
</plugin>


If your project uses Any android platform plugins for instance Google maps, additional dependencies will also require referencing in the project’s pom:

<dependency>
  <groupId>com.google.android.maps</groupId>
  <artifactId>maps</artifactId>
  <version>8_r1</version>
  <type>jar</type>
</dependency>
<!-- Current versions:  3, 4_r2, 7_r1, 8_r1 -->
<!-- NOTE: those are the ones defined by goole and are  NOT in the maven
central repository and need to be installed manually with:
mvn install:install-file wih proper parepeters as decribed here:

http://maven.apache.org/plugins/maven-install-plugin/usage.html

e.g. mvn install:install-file
-Dfile=$ANDROID_HOME/add-ons/addon_google_apis_google_inc_8/libs/maps.jar
-DgroupId=com.google.android.maps -DartifactId=maps -Dversion=8_r1
-Dpackaging=jar -->


Additionally one should remember to specify the source directory if the folder structure does not follow the default maven structure:

<sourceDirectory>${project.basedir}/src</sourceDirectory>


At the same time remember NOT to specify the resource directory, as maven-android-plugin handles Android-specific resources on its own, and we don’t wnt duplicates.

This will already get your project building, but there’s much more that maven can do for You. Let’s look at some of that now.

Testing your App with an Instrumentation

You most hopefully have an accompanying instrumentation test instrumentation project for your Android application and maven can build and run these against your previously compiled project. Maven can build the test project, deploy both the app and the test, and run the instrumentation on an attached device or an emulator.

Within the instrumentation test project it will need the following dependency:

<dependency>
   <groupId>com.google.android</groupId>
  <artifactId>android-test</artifactId>
  <version>2.2.1</version>
</dependency>
<!-- Allowed values same as for android package -->
 


If it depends upon the source code of the application which it tests:

<dependency>
  <!-- optional: compile time dependency, in this case so that we can -->
  <!-- read from the R.java for example. -->
  <groupId>my.app.group</groupId>
  <artifactId>myapp</artifactId>
  <version>${project.version}</version>
  <scope>compile</scope>
  <type>jar</type>
</dependency>


Instrumentations are run through a series of interactions within a pseudo environment so you will need to specify the Device/AVD(Android virtual Device) upon which you wish to run tests:

<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>maven-android-plugin</artifactId>
  <configuration>
  <emulator>
    <avd>22</avd>
    <!-- name of the avd to deploy to and run the instrumentation on -->
    <wait>150000</wait> <!-- wait time for the emulator to start -->
    <options>-partition-size 128 -wipe-data</options>
    <!-- additional options to run the emulator with-->
  </emulator>
  <undeployBeforeDeploy>true</undeployBeforeDeploy>
</configuration>


Devices to deploy to can be specified by a serial number but generic “usb” and “emulator” values are also valid. More detailed documentation can be found here.

Instrumentation environment

Instrumentations can interact at various hook in points during the a devices connected lifecycle. Execution and binding it to a maven lifecycle phase is specified like:

<executions>
  <!-- android plugin execution that starts the emulator. -->
  <execution>
    <id>startemulator</id>
    <!-- bound to the 'initialize' phase -->
    <phase>initialize</phase>
    <goals>
      <goal>emulator-start</goal>
    </goals>
  </execution>
</executions>


The configuration above binds the android plugin’s ‘emulator-start’ goal to the ‘initialize’ phase of the maven lifecycle. This is the equivalent of manually executing mvn android:emulator-start, from a directory with a pom containing valid configuration for it. Stopping the emulator does not require this and can be run anywhere and anytime with mvn android:emulator-stop.

If we would like to stop the emulator after running the instrumentation tests, we would add the following execution:

<execution>
  <!-- android plugin execution that starts the emulator. -->
  <id>stopemulator</id>
  <!-- bound to the 'install' phase -->
  <phase>install</phase>
  <goals>
    <goal>emulator-stop</goal>
  </goals>
<execution>



Signing your release

By default, the plugin will sign the apk with the debug key. This can be disabled, producing an unsigned apk.

<configuration>
  <sign>
    <debug>false</debug>
  </sign>
<configuration>


To sign and apk with your key, we will need to use the maven-jarsigner-plugin. Although it’s a different plugin, since it’s very relevant here’s how we did it:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jarsigner-plugin</artifactId>
  <version>1.2</version>
  <executions>
    <execution>
      <id>signing</id>
      <goals>
        <goal>sign</goal>
      </goals>
      <phase>package</phase>
      <inherited>true</inherited>
      <configuration>
        <includes>
          <include>
${project.build.directory}/target/${project.artifactId}-${project.version}.apk
          </include>
        </includes>
        <keystore>${keystore.location}</keystore>
        <storepass>${keystore.password}</storepass>
        <keypass>${keystore.keypass}</keypass>
        <alias>${keystore.alias}</alias>
        <verbose>true</verbose>
      </configuration>
    </execution>
  </executions>
</plugin>


Configures the jarsigner plugin with the files (input, output), and the keystore details. Binds the plugin’s ‘sign’ goal to the ‘package’ phase of the maven lifecycle.

The ${kestore.*} variables above come from the settings.xml file, and look:

<properties>
  <keystore.location>path/to/test.keystore</keystore.location>
  <keystore.password>teststorepass</keystore.password>
  <keystore.keypass>testpass</keystore.keypass>
  <keystore.alias>testkey</keystore.alias>
</properties>



Optimization .apk files via zipalign.

The last stage of a deployment, but also very important is zipaligning the apk after it’s been signed. This aligns archived data in such a way that upon runtime memory can more efficiently store the related data. After this your apk is ready to go to the market. our configuration:

<plugin>
  <groupId>com.jayway.maven.plugins.android.generation2</groupId>
  <artifactId>maven-android-plugin</artifactId>
  <configuration>
    <zipalign>
      <verbose>true</verbose>
      <skip>false</skip><!-- defaults to true -->
      <inputApk>
    ${project.build.directory}/${project.artifactId}-${project.version}.apk
      </inputApk>
      <outputApk>
    ${project.build.directory}/${project.artifactId}_v${project.version}.apk
      </outputApk>
    </zipalign>
  </configuration>
  <executions>
    <execution>
      <id>zipalign</id>
      <phase>verify</phase>
      <goals>
        <goal>zipalign</goal>
      </goals>
    </execution>
  </executions>
</plugin>


Configures the plugin for the zipalign goal and binds that goal the the ‘verify’ phase of the maven lifecycle.

Real Life Example

The above describes taking full control over how maven-android-plugin builds and tests your android application. In reality though, one wouldn’t really use all of the above settings in one pom. Here’s an example of a fully-configured real-life project using ALL of the above:

weeworld
      |— WeeWorld
      |          |— pom.xml
      |— WeeWorldTest
      |          |— pom.xml
      |— pom.xml



The project makes use of a parent-child structure and maven profiles to manage both App and Instrumentation projects and handle different cases of builds. Feel free to have a look and se how we’ve done it. For more guides and tips about android development and continuous integrations check back to our blog – we’ll have something here soon!

Topics to expect:

  • Project relashionships and inheritance
  • Maven profiles
  • Hudson configuration
  • Automatic instrumentation testing on many different AVD’s using Hudson Android Plugin



References:

maven-android-plugin site, the Getting Started guide and their wiki page.
Installing a specific file into a local maven repository
Signing apk files with maven
Zipalign apk files with maven-android-plugin

Other relevant and important resources:

Maven: The complete reference book and it’s Android Chapter

15 Comments

Observations from Google IO 2009

Google IO 2009 was held in sunny San Francisco and Novoda’s presence acted as a technical bridge for the Royal Veterinary College, London Knowledge Lab and the wider Bloomsbury Colleges as they further explored Google’s Android platform as a potential tool for the collection of medical & veterinary data. As I was acting on behalf of Academia the trip was very kindly funded by JISC, so a big thank you to them.

Google event’s are renowned for merging developers’ unique personalities with the approachable yet cutting edge image of Google technology. There were brightly coloured bean bags, qr-code scavenger hunts, make shift Google street view holo-chambers, arcade cabinets and robot wars but they were all in aid of furthering the interaction of developers and getting them conversing on areas of tech. As if the fact that all the attendees received free G2 HTC magic phones was not reason enough for conversation.

Talks

The talks were generally of a very high standard with a whole section dedicated to each Google interest  including mobile (Android). Outside of each speaking area was an alcove where Google advocates were freely available for questioning on the intricacies of each specific technology. Each recorded session lasts about an hour so specifically, I recommend watching the following:

Writing Real-Time Games for Android w/ Chris Pruett is well delivered with captivating game development content. Chris considers the resource usage on Android from the perspective of a developer used to a similarly constrained C++ mobile environment.

Android media framework w/ David Sparks contains good graphical representations of media call life cycles from the native system upwards and addresses the techniques while dealing with all forms of media.

Coding for Life — battery life, that is w/ Jeffrey Sharkey offers a primer on how to be mindful of your applications specific actions how they are affecting a device’s power consumption.

Supporting Multiple Devices with One Binary w/ Joe Onorato & Romain guy addresses the problem of standarising the presentation of a UI of multiple ‘densities’ on different devices.

Although not based on Android, another talk which is well worth mentioning was the second day’s big topic of conversation ‘Google wave’ which it has to be said is an exciting convergence in persisted communications.

Attendees & Exhibitors

It was difficult choosing to not attend talks and venturing away from the Android alcove but there were some worthwhile exhibitors.

EA consistently sets a high technical standard on all platforms and the same can be said about their android offerings, Sim city, The Sims, Tetris and Monopoly. Close by them was the extremely nice Spotify (premium content) app which sports intuitive & innovative UI design. Each of the bottom tabs can be slid upwards to reveal a more detailed selection of options within that tab’s context which is a nice touch on an already very usable app.

Mobile media company 1Cast were showing off thier app’s streaming capabilities and the fact that it can search through a huge catalogue of their partners premium content. The very snappy responsiveness signals a mobile media viewing experience which is slowly entering the big leagues.

Swedish Game development company Illusion Labs had their games on show including my personal fave ‘Labyrinth’. Labyrinth works the same as the traditional wooden games but the real charm of this particular port is that it provides such pleasant tactile feedback whenever your metal ball hits against the sides of the wooden box. The subtle feedback makes this an exemplar experience for tactile interaction within mobile games.

Catalista also had a very nice location aware application which allows user to find nearby volunteering opportunities.

Some guys from Tubaloo demonstrated a personalised VoIP build of android which they are planning to soon offer the Latin American market. The threat of VoIP to traditional phone services has been looming on the horizon and we’ve recently seen some movement from Skype onto cellphones but could this signal the start of competition in this market?

Also worth a notable mention even though they weren’t technically exhibiting was the Czech Republic based company Inmite who impressed me with both their development knowledge and their popular ‘Lokola’ application which finds searches through the online portal’s directory of resources relative to the device’s global positioning.

Post Google IO

Eager to network with universities, I was surprised to speak with very few groups doing exploratory research on Google Android especially since I encountered such wide acknowledgment of it’s potential in this area. There were the notable exception of San Francisco State University who are just beginning to look into the possibilities of mobile applications within their current work in blood & disease analysis. Hopefully we can soon establish some talks between them and RVC to exchange experiences. If you yourself know of universities working on with the Android platform then please do contact us!

I was lucky enough to spend some time with the developers from the well intentioned ODK project who are developing free tools to aid the collection of standard data by providing an easy click through forms interface. They wished to emphasize their eagerness to receive participation and feedback which I hopefully helped them with by suggesting some commercial and academic use cases.

Some of  the world’s largest media networks for games, music and television were at Google IO to show off their polished offerings to a standard which has until recently has been reserved for the IPhone. This is encouraging because as industry draws attention to the platform, media companies will invest in the relevant training and as a by product we should hopefully see an explosion of free and organisational offerings. ADC2 itself would usually have had entrepreneurial developers inquiring into Google’s offered cash prize but team this with the fact they have given free devices to their most loyal developer audience ensures that there will soon be fresh activity hitting the Android market.

Android SDK at time of writing was: 1.5_r2

Citations & Research

0 Comments