Automating Android Builds
In order to have a fully regression tested application, it is necessary to have an automated build process to ensure all checkins are validated nightly ( or whatever your schedule is). This is a simple task for most Java projects, however you may run into some issues with Android that I point out here.
- If you started your project from Eclipse, you may not have the Ant build file and supporting properties file in your project
- If you want to sign your application with a key, the default build keeps prompting you for the keystore password
Both of these are relatively easy to over come and here is a great article on StackOverflow. My only goal here is capture it all in one place.
The first thing to do, is to make sure that your android SDK folder is on your path. In order to do that, just update your local .bash_profile in your home folder to include the following paths:
#!/bin/sh export PATH=$PATH:$HOME:$HOME/Documents/Development/android-sdk-macosx/tools:\ $HOME/Documents/Development/android-sdk-macosx/platform-tools export ANDROID_HOME=/Users/Kouroche/Documents/Development/android-sdk-macosx
Note the \ in the first export command. It is there to split the command over two lines, but you don’t need that in there. This will not only add the Android SDK to your path, but also define ANDROID_HOME which is used by the build file (more on that later).
At this point, you will either have to logout and login again, or source .bash_profile to make sure the changes took effect. To verify, run the following command from your home folder:
$ android list targets
In order to add the build files to your project, you can either create a new project from the command line and copy those build files to your project, or you could update you project from the command line to add in the build files.
Creating a new project
In order to create a new project from the command line, run the following command:
$ android create project --target
--name MyFirstApp \ --path /MyApp --activity MainActivity \ --package com.acme.myapp
The app name nor the package matter. The only thing you may want to match to your current application is the <target-id>.
Once the project is created, copy over the following files to the root of your own project and then delete this app folder.
- ant.properties – This is where you store your project specific properties for Ant
- build.xml – This is the generic build file provided by the Android SDK and will most likely not need changing
- local.properties – This file contains the path to your SDK, but I prefer not to copy it over since it may get checked in by mistake.
- progaurd-project.txt – This file contains ProGaurd rules if you choose to obfuscate your code, and more can be found here about that.
- project.properties – This file contains the target for your project and is most likely already part of your project.
Updating your existing project
This is probably your best bet since it is less of a hack and should add the same set of files to your project.
$ android update project --name
--target \ --path
Once again, make sure to use the same <target-id>
Customizing the build
Now that you can use Ant to build your project, you may want to customize the build process to meet your needs. For example, I always include a build ID somewhere in the application so users can report which build they are on when reporting issues, or you may want your release build to point to a different backend server than your debug build. In any case, the Android SDK makes this also very easy.
Looking at the build file, it optionally imports a custom_rules.xml file that you can create in your project root folder to hook into the build process. The build file even lists out the targets for your to include. Here is a sample one I created:
What this does, is to update the build ID in my constants class, and also update the backend server my app talks to depending on whether it is a release build or not.
Signing the app
One of the issues I mentioned early on, for the need to have build automation, was having to provide a password each time the app needed to be signed. Well, the key to solving this problem is the ant.properties file which includes your project specific properties.
Unfortunately, i have not found a way around having to include your password in plaintext in some form or fashion so that it can be used, but if your an individual or have a designated build person or machine, you can lock the file down pretty good.
So, to get back to the issue at hand, include the following four lines in your ant.properties file and you are good to go:
key.store.password= key.alias= key.alias.password=
If you have been building with Eclipse for while and don’t recall your keystore alias, an easy way is to go through the export process in Eclipse to release the app and see what the keystore alias is.
The build command
OK, so now that it is all set, the easy part is building the application. You can run either of the following commands to build the app for debug or release respectively.
$ ant debug or $ ant release