Building is the necessary part of Android application development. In the simplest case building is changing the version and acquiring the signed *.apk file. It’s easily done with the popular Eclipse IDE.
This variant is optimal for single programmers who create small applications. Development of the large-scale projects calls the additional requirements, such as:

Using the automatic building system (and executing tests)

Adding some special stages to the building process

Using differently configured builds

It’s nearly impossible to use Eclipse in such cases. But fortunately Android SDK supports Apache Ant.

Apache Ant is a tool for applications build process automatization, widely popular among Java programmers. It can help us in cases when using Eclipse is difficult or impossible. To perform an action in Ant you must write a build script on XML. Build script contains one project and at least one target. The target in the build script is a pack of tasks applied for execution for target call. The task is just some code. Also the important part of build script is properties. They are used to determine the variables in built files.

Software requirements

This manual requires the following software installed on your machine:

Target_ID – corresponds to the Android platform library version used for building. The list of available libraries can be seen by executing the command “android list targets”

your_project_name – the name of the project

path/to/your/project – directory to place your project into

your_activity_name – the name of Activity

your_package_namespace – the name of application package

Signing the Andriod application

Android OS requires all the applications to be signed with the certificate owned by developer. If the certificate is lost, you become unable to update your application. Also notice that all the builds created throughout the development workflow are signed with the special DEBUG certificate. But you cannot use it to install the build to the device or publish it to Android Market. More information about signing the applications is available in Android OS documentation.[5].

To prepare the build for publishing we need to:

Create a certificate (only once)

Create a build

Sign the build with the certificate

Eclipse includes a special wizard to perform this action (Project Properties -> Android Tools -> Export Signed Application Package…). We need to automatize as more tasks as possible, and steps 2 and 3 are the main target for that. To perform this we should put the certificate information to the ant.properties file (in older Android SDK versions it’s called build.properties). If there’s no such file in the project directory – you must create it.

Creating differently configured builds

Usually programmers create a lot of different builds when developing an application: for themselves, for testers, for customer… These builds can differ significantly. For example, the programmer himself wants to get more information to log (logcat for Android), but for release build this is not needed. The build intended for Market may include the statistics-gathering functionality. If the programmers’ and testers’ builds will also gather it, this may distort the statistical data. If the application is published not only in Android Market, but also somewhere else (Amazon AppStore, GetJar etc.), it’s best to add the error-reporting functionality to ensure the fastest bugfixing. But the error-reporting must be disabled in development builds, otherwise all the current (and corrected) mistakes of the programmers will flood the report.

To make things simpler we will shorten all the configuration to the only DEBUG parameter. You can easily add the rest of the parameters by yourself.

Create 2 files containing this parameter for development build:

packagecom.enterra.android.apps.test.settings;/**
* This is configuration file for development-builds.
* If you want to change it – edit file <project_root>/dev_config/Configuration.java.
* Then use Ant script for switching between configurations.
*/publicclass Configuration {publicfinalstaticBoolean DEBUG =true;}

and for release build:

packagecom.enterra.android.apps.test.settings;/**
* This is configuration file for release-builds.
* If you want to change it – edit file <project_root>/release_config/Configuration.java.
* Then use Ant script for switching between configurations.
*/publicclass Configuration {publicfinalstaticBoolean DEBUG =false;}

The first file will be placed in “<project_root>/config_dev”, and the other in – “<project_root>/config_release”. Also we need to copy one of them to the source code directory. In my case it’s: <project_root>/src/com/enterra/android/apps/test/settings.

Now we will include the settings-changing code in the script, which will alter the settings depending on the task.

Application version

android:versionCode – inner version number (integer value). Used to determine the latest version available. It must be increased with every released version. In Android OS it can be seen only through Application Manager

So we need to make android:versionCode increase by one with every release version. As for android:versionName, we will generate the version number from 2 parts: major and minor. The major part will always be changed by developer. The minor part is to be increased by one with every build.

To make this possible we will create a <project_root>/version.properties, file containing the current version information:app.version.code=10
app.version.major=1.0.
app.version.minor=4

This script takes app.version.code and app.version.minor properties from <project_root>/version.properties, , increases them by one and saves. Then it refreshes android:versionName and android:versionCode attributes in the AndroidManifest.xml file.

This task can be executed separately to ensure the proper functioning:

Interaction with VCS (version control system)

The final important thing to point out is the rules of interaction with VCS and created files.

The local.properties file must not be placed into the VCS

It’s necessary to add ant.properties, version.properties, default.properties and build.xml files to the VCS

It’s also necessary to add the configuration files (config_dev/Configuration.java, config_release/Configuration.java).

The developers must not include local config file (
/src/…/Configuration.java) changes into the VCS. This is not applicable to new parameters adding.

After creating the release build it’s necessary to create a tag for it. This is to make errors tracking easier when receiving error-reports.

Conclusion

In this article we described the creation of a script which helps to reduce the amount of time needed to build a project. Regarding a fact that building process may include a large amount of stages, we not only gain time economy, but also reduce the risk of errors (which can be implied on every stage). The described functionality is applicable for virtually every project. The further development of build script depends on the project. Using this information you shouldn’t experience any difficulties in adding new steps to the build script.