aapt: AndroidManifest.xml already defines versionCode; using existing value in manifest

[Ievgenii Nazaruk]

Here is my use case:

1. I develop applications in eclipse. And therefore I use
AndroidManifest.xml to define default values for "versionCode" and
"debuggable" attributes for comfort development workflow. Those values
are hard-coded and almost never changed.

2. When I want to build release version of application, I go and run
my customized ant build script which uses Android's build system
rules. This ant script overrides values of "versionCode" and
"debuggable" by using aapt's command line options "--version-code" and
"--debug-mode".

This was working some time ago. I could override values in
AndroidManifest.xml by using customized build script. This however
does not work anymore and final .apk file has values from original
AndroidManifest.xml. And I also receive warnings during the build:

[aapt] Warning: AndroidManifest.xml already defines versionCode
(in ...); using existing value in manifest.
[aapt] Warning: AndroidManifest.xml already defines debuggable
(in ...); using existing value in manifest.

And same is true for any attribute that can be overridden from aapt
tool. Code that is responsible for this warning message: http://tinyurl.com/6f69vcq.

Is this expected behavior? Or should I report it as a bug?

[Xavier Ducrohet]

I'm not too familiar with this part of aapt but AFAIK this has always
been the behavior (or at least of 1+ year, as I saw this behavior in
Q2 '10 when I did some test using this part of aapt).

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Ievgenii Nazaruk]

You're right. I looked through logs on that part of aapt and it seems
I was wrong that aapt behaved differently sometime ago.

I revised my old build system and it turned out that it simply
modified AndroidManifest.xml during the build. And even more, I looked
through several other projects with automated build systems and it
looks like everybody is modifying AndroidManifest.xml too. Some build
systems revert changes back, some do not do this. But even those which
revert changes still can be killed in the middle. Which again results
in modified AndroidManifest.xml. And AndroidManifest.xml is stored in
version control system, which results in some noise committed into
repository.

Are there any strong reasons for not allowing to override mentioned
attributes from withing aapt tool? I'd change that code to allow
overriding with warning in logs.


List of attributes that aapt can set (if they were not set in
AndroidManifest.xml):

1. versionCode
2. versionName
3. minSdkVersion
4. targetSdkVersion
5. maxSdkVersion
6. debuggable

I'd be happy to see at least `vesrionCode` and `versionName`, and
maybe `debuggable` to be overridable from aapt. I can submit a patch
for that :)

> Google Inc.http://developer.android.com|http://tools.android.com

[Xavier Ducrohet]

To be honest I'm not sure why it was done this way but I can see a point for it.
If there's a value in the manifest, it would be dangerous to have it
be overridden without knowing about it. Of course this is probably
more important in our case where our complex build system builds the
whole device system image, including bundled app, and developers (of
said bundled app) may not know what the build system passes to aapt.

I would like to see the build system be able to set those values
either from the command line of ant or through a value in
default.properties for both ADT and Ant.
It would allow you for instance to have default values in
default.properties but override them with different values when you
build your release package with ant.
In this case, I think it's fine if it requires that the manifest does
not contain these values in the first place.

Xav

[Xavier Ducrohet]

oh and BTW you really should not touch debuggable at all. The build
system already sets this (through the aapt command line) based on you
build target (from ADT and Ant).