Update: This way of deploying multiple targets is considered outdated. There is a better way now.

This posting is about how to create multiple versions of your Android application without cloning the whole project. For example if you want to create a full (paid) app, as well as a lite (free) version of it, you might want to automate the task of switching between them. Both versions should be able to use different graphics, different strings and even different featuresets.

First of all, what causes trouble with multiple targets on Android is the auto-generated source code and the strict checking of Java. Strings and graphics are all kept in one place, namely the res folder. Simply creating one res folder for each target and switch between those folders solves the problem with all resource files. I will give an example Ant-script for this later on.

So, having different resource files seems easy. But there is one more problem. We want to have two different applications, so both targets don’t replace each other on our phone. Meaning, the targets need a unique package name in the AndroidManifest.xml. And it’s getting worse. When changing your applications package name, you also change the package of the automatically generated R file. This R file usually is referenced in a lot of source files – basically everywhere you need graphics, strings or other resources. So you end up editing a great amount of your sourcefiles when changing the application package name.

What is the trick over here? Well, I don’t have any. My approach goes through every Java file and changes the import statement for the R file:

There are several targets in this Ant-script. The default target is myproject, the others depend on the default target (for example myproject is always executed before the otherResources target). myproject does the following:

• deletes the current res folder
• copies its own customized resources into res
• replaces all ocurrences of “import com.android.multiple_targets(.*).R;” with “import com.android.multiple_targets.R;”. This might be necessary if the iamdifferent target changed it to “import com.android.multiple_targets.iamdifferent.R;” for example.
• the package name in the AndroidManifest is changed to the target name

Just execute a target to switch to this version of your app. You need to refresh the project in order to reflect the changes. In Eclipse, this can automatically be activated by setting the following option:

One more thing that does not work out of the box is the android:name parameter in activity declarations of the AndroidManifest. When auto-generated, they are declared relative to the project package. This doesn’t work anymore when the package name is changed. Therefore you have to set the activity name with absolute values. Instead of

<activity name=”.Test”>

You have to write something like

<activity name=”com.android.multiple_targets.Test”>

For all of you who like free lunch, here is an example project with two targets ready for download.

This is how three targets of the same app look like:

Thats it. With this approach you can deploy as many customized versions of the same project as you want. If you are missing a step or know an optimization of this, please leave me a comment.

(this entry is cross-posted from my old blogger site)