5

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!

Community
  • 1
  • 1
Boris Strandjev
  • 46,145
  • 15
  • 108
  • 135
  • basically your asking if we could have keys that will be accepted as values by Eclipse and would be replaced in by build script? – Eugen Martynov Aug 29 '12 at 10:58

2 Answers2

2

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.

Eugen Martynov
  • 19,888
  • 10
  • 61
  • 114
  • Thank you for the quick answer! It will take me some time to verify its validity so please be patient. – Boris Strandjev Aug 29 '12 at 11:29
  • I would only like to mention that I turned out to need to add a lot of move tasks, because basically all my java files needed to change package accordingly. Still: your proposal works like a charm! Thank you! – Boris Strandjev Aug 31 '12 at 07:29
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.
MH.
  • 45,303
  • 10
  • 103
  • 116
  • Thank you for your answer. Still I would like to add that if you introduce Jenkins in your build process, things will become even simpler. I personally did my job only using few ant tasks that basically copied all my files to new packages. Also as I use ant I think property files are more convenient than xml files. – Boris Strandjev Aug 31 '12 at 07:28