Monthly Archives: December 2009

When creating an application that will be distributed to more then your self you want to do it the proper way. So far I have looked at how to automate the build, testing and both using Maven, as well as how to sign the apk. What is still outstanding is to run zipalign, a tool in the Android SDK to optimise the package.

To understand what the zipalign tool is you will find Androids documentation here.

It is a simple thing to add the command to the pom file. I am assuming that your project structure looks like the examples build in the previous posts.

In the pom for your application you need to add the following snippet:

This will bind execution of zipalign to the package phase, just after the apk signing, when running install with the sign profile. It will overwrite previous zip aligned file without asking.

One function that have not yet made it in to the Maven Android plugin is application signing (it is raised as an issue). It is however possible to achieve this using the maven jarsigner plugin with some simple configuration of the pom.

It is assumed that you are using the project structure presented in previous blog posts on maven android automation (1, 2, 3)

In your parent pom you add the following profile:

Replace the following values in the above snippet:

  1. keystore the path to your key store.
  2. keypass the password for the key that will be used.
  3. storepass the password for the key store.
  4. alias the alias for the key to use.

To sign the apks, including the tests, use the following command:

The configuration will bind the jarsigner plugin to the package phase of the execution when enabled with the -Psign switch in the build. Rather then storing the passwords in clear text in your pom you can pass them to maven as arguments when you execute the command. Go to the jarsigner plugins documentation page for information on how it works and how it can be configured.


The last post explored how to automate a Android test project that is associated with an Android application. It also introduces some unneeded complexity in how each project has to be built individually for the tests to run. This is easy to do away with by using Mavens built in project hierarchy.

To achieve this a new directory needs to be created. In the new directory the two android projects (the application and the test projects) should be placed. Ensure that the names of the directories matches that of the artifact name specified in the pom for each project.

Now a pom.xml needs to be created that holds information which is similar for both project and also reference the two projects. Mine look like this:

It is important to note what the names in the modules section are. They need to correspond with the directory names of the two modules, and the directory names should in turn match the artifact id's of each of the modules.

Next we will need to change the pom files of the two modules, the application and test pom files. The following needs to change:

  • The build section can be removed. It will be inherited from here.
  • The child projects need to know it's parent. This is done by adding the following to the top of each pom:

  • In the dependencyManagement section in the parent pom the version number and scope for the android jar file is specified. That makes this information is redundant in the child poms. So removing it will ensure clean build files.

Once this is done you can go to the directory where your parent project is and run the command:

This will trigger the build and test of your Android project.

Having done this it is very simple to add your Android project to your favorite CI server. What you need to keep in mind is that in order for the tests to work you need to have either a connected device or a running emulator.


The last post explored how to enable Maven builds in a standard Android Eclipse project. This post will show how to enable the test project to be built with Maven.

It will be a bit simpler to enable Maven builds in the test project since we will not need to do any of the prep work. The only thing required is to create a pom file for the test project:

This pom is similar to the pom in the main project but has two more dependencies. They are both pointing to the main project, one to the apk and one to the jar file. The dependency to the jar file is to enable the compiler to find your java classes from the main project. The dependency to the apk is to enable the android maven plugin to find the apk that it will run the tests against on the device or emulator when executing.

The android maven plugin can now run the tests using instrumentation, just like Eclipse does, as long as an emulator or Android device is connected. It uses the same underlying tools.

In order to execute the test the main project needs to be built and installed into the local Maven repository. This is done with the mvn install command in the main projects root folder. When the main project have been installed the same command, mvn install, will build and execute the tests when executed from within the test projects root.

Next post will explain how to create a project hierarchy that makes it possible to build and test the two projects with one command.