Customizing parts of Android Manifest

Question

I am developing Android application for which I want to ship several different apks for different languages in the market (every language includes a huge bundle of files and I want to avoid creating one huge apk with all language bundles).

So what I need is to customize a bit the Manifest file for each language: e.g. the package of the application and possibly the application version etc. I know how I can template the manifest so that I can manually insert my values in certain points in the file (see this post). The problem is that I use ant for preparing my production apks, but otherwise I develop using Eclipse and so I need my project working in the IDE too. Eclipse requires complete Manifest file and will not understand of the templating I will use for the ant builds as far as I know (please somebody prove me wrong).

My problem is that I want to avoid maintaining two manifest files that are identical in large part (one templated and one complete for Eclipse). Currently I can think of two possible approaches, but I do not know how to accomplish them:

• Use some kind of definition injection in the manifest file: if I am able to inject certain xml file in the body of AndroidManifest file, I can keep the identical part in one xml part and customize only the points of difference
• If it is possible to configure Eclipse to use some sequence of ant tasks to build Android projects instead of the prebuild routines I might be able to integrate the way I build my production apks in the IDE.

Please if there is anyone who knows how to accomplish any of the above two, or has any other idea how can I solve my issue: help!

Answer 1

Take a look on ant replace task:

<replace file="${build.out}/src/config.prop" token="@@@" value="${build.version}-${build.type}"/>

But again you should be careful with values that they are unique.

You could also replace your eclipse manifest with generated manifest by echoxml task.

Or you could reuse this nice task about xml manipulation.

Answer 2

At the company I work for, we pretty much use the approach given by Eugen to automate the build process of apps that e.g. should simply be branded differently by exchanging certain assets, styles, strings and configurations. We tend to set up the project and build process as follows:

1. Create the Android project and set it up such that it works for a specific branding. This will make sure that you can still build and run from Eclipse. Assuming that the codebase does not change between differently branded releases, that should be fine.
2. Create an ant build configuration that:
   1. copies any files that are going to be changed to a backup directory
   2. modifies the project files according to a configuration file (see below)
   3. compiles the project sources and signs it with a release key (if making a release build)
   4. copies back the files from step 1, overwriting any changes and returning the project to its original state
3. Create configuration files for every 'branding', or language specific release in your scenario.

Basically these steps will allow you to create branded/partner/language specific builds by simply providing the appropriate configuration with the ant build command. In our case it looks somewhat like this:

ant partner-release -Dpartner=stackoverflow

where 'stackoverflow' will point to a configuration with the same name. In our case these configuration files are small xml files that contain all the parameters that are to be replaced for that specific build. It could contain strings, but might as well point to other files (e.g. logo images) that should be copied into the assets/resources. For example:

<config>
    <version_name>1.00</version_name>
    <version_code>1</version_code>
    ...
</config>

Some more pointers:

• We use xmltask to modify any xml files in the project; e.g. the manifest and resources.
• Since the aforementioned task is really easy to use, our build configuration files are also set up as xml files, as illustrated above. It's quite human readable and easy and straightforward to change.
• You can also use replace and ReplaceRegExp tasks to change configuration-dependent variables in almost any file. The latter can be especially convenient to make build-time changes to source code.