Android: Deploying multiple targets from one project (outdated)

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*).R;” with “import;”. This might be necessary if the iamdifferent target changed it to “import;” 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=””>

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)

6 Replies to “Android: Deploying multiple targets from one project (outdated)”

  1. Hi,I have downloaded your example project but I couldn’t find a way to run it using my eclipse IDE. Can you please guide me how to do so?

  2. You should tell something about the problem, if you seek for help.

    Anyways, I have to admit that this way of deploying multiple targets is outdated. There is a more comfortable setup with library projects now.

    Gotta write an update when I have some spare time.

  3. Hello Mr. Scheller,
    I am using NetBeans and I used your script for generating Test and Production version of my app. I pasted it into build.xml file, I have it as a build configurations. They are completed successfully, but I run e.g. iamdifferent target, but no APK is created. Then I click on debug, APK are signed and created, but only with the default packages and manifest. Strange is, that resources are appended normally. Do you see, where can be problem?


  4. Did you paste the “multiple targets.xml” into build.xml? If so, this is not the way it works.

    The “multiple targets.xml” is used to switch between two or more targets inside the same project. It does not replace the build.xml, which is created automatically by the android framework.

  5. This example is great for having different targets with customized resources. But how do you solve the problem of having customized code (for example – add a code line in a class for one target only)?

  6. I defined features that could be enabled/disabled in an xml file. The code checks whether the feature is enabled and then executes the special case code.

    However, if you want to have different targets with changes in the code, I encourage you to use a library project instead.

Comments are closed.

Recent Posts


Recent Posts