Release version management for your Android application

Today I am going to explain an improvement I made to the MorseFlash example application that I created as part of the Maven Android Plugin samples. It will help by automating the management of the version name and code. But one thing after the other.

First of all to play around with it yourself you should download my clone of the Maven Android Plugin Samples and set up your machine to build your Android application with Apache Maven. Once you have seen what you can do you can take advantage of the this automations by building your Android application with the Maven Android Plugin.

With the help of the Maven Release Plugin you can automate the process of doing a full build, updating version number, creating a tag in your version control system and revving the version to the next iteration. All this help works with the version as defined in the Maven pom.xml of your project. The only problem is that an Android application stores its version information in the versionCode and versionName attributes of the manifest property in the AndroidManifest xml file. Now with the following setup you can get the version from the pom.xml automatically into the AndroidManifest. But first lets understand the different version numbers.

First of all the version number in the Maven pom file should be following ea scheme of x, x.y or x.y.z scheme with xyz integer numbers so that the release process automation works nicely. You can use any other scheme but especially the x.y.z scheme are well understood and supported, so I would suggest to use that scheme unless you want to create additional pain for yourself..

Next the versionName in the AndroidManifest can be any string that is going to be shown to the user as a version string. Typically it is also of a x.y.z scheme.

Last but not least there is the versionCode property in AndroidManifest that is required to be an integer number that increases from one upload of your application to the Android market to the next.

In order to automate this we are going to have our master version in pom.xml. During development we use e.g. 1.0.0-SNAPSHOT. The release process would up this to 1.0.0, tag in version control system and then move on to 1.0.1-SNAPSHOT. It would also build off the new tag with the 1.0.0 version. The setup I will describe shortly will set the versionName to 1.0.0 and the versionCode to 100 automatically and here is how it works:

In the AndroidManifest.xml file we set up the versionName and versionCode with Maven properties like this:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  android:versionName="${project.version}"
  android:versionCode="${parsedVersion.majorVersion}${parsedVersion.minorVersion}${parsedVersion.incrementalVersion}"
  package="com.simpligility.android.morseflash">

Now in order to get the properties setup from the values in the pom.xml file we have to do the following. We have to add the AndroidManifest to so it gets filtered:

<resource>
  <targetPath>${project.basedir}/target/filtered-manifest</targetPath>
  <filtering>true</filtering>
  <directory>${basedir}</directory>
  <includes>
    <include>AndroidManifest.xml</include>
  </includes>
</resource>

And then last but not least we have to get the replacement by the resource plugin early enough in the build by binding the resource plugin to

<build>
  <plugins>
    <plugin>
      <artifactId>maven-resources-plugin</artifactId>
      <executions>
        <execution>
          <phase>initialize</phase>
          <goals>
            <goal>resources</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

and in order to have access to the parsedVersion values we add the handy dandy build helper plugin like this

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>parse-version</id>
      <goals>
        <goal>parse-version</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Last but not least you need to tell the Maven Android Plugin that it should use the filtered manifest file by adding this

<configuration>
  <androidManifestFile>${project.build.directory}/filtered-manifest/AndroidManifest.xml</androidManifestFile>
 

to the plugin configuration. And voila.. thats it. This will work for versions where each sub number stays single digit. If you need to go higher you will have to change the usage of the parsedVersion to ensure that the resulting versionCode is always increasing. That should be a simple change but depends on which numbers you are revving higher.

I hope that helps and that you come back next time when I will explain how to take care of different configurations for development, staging/QA and production.

See you then

Manfred

8 comments » Write a comment

  1. Hi,

    How is ADT handling the versionCode in the manifest?

    Thanks.

  2. I’m sorry but I was not clear. I meant to ask how can this be handled in ADT. The actual error is “error: Error: String types not allowed (at ‘versionCode’ with value ‘${parsedVersion.majorVersion}${parsedVersion.minorVersion}${parsedVersion.incrementalVersion}’).”
    Is this approach final and should I address this issue to the m2eclipse-android-integration?

    Thanks.

  3. Any news on the last comment of Alex about the Error: String types not allowed (at ‘versionCode’ …?

  4. I have since changed this but in any case the normal build on the command line works. If the m2 eclipse android integration does not work you have to create an issue for it on its project site. It might just be picking up the unfiltered manifest file.

  5. Thanks, that is helpful. Don’t know why manifestVersionCodeUpdateFromVersion doesn’t work, but Your trick does. :)

Leave a Reply

Required fields are marked *.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>