Changing the Android Version Code for the Goole Play App Store

[b]My problem: [/b]The Android version code needs to be incremented to publish a new version of an APK file to the Google Play App Store. [b]This problem: [/b]NME hardcodes the version code and version name into AndroidManifest.xml [b]Prereqs: Signing…

Viewing 1 to 10 (10 Total)
Changing the Android Version Code for the Goole Play App Store

Markavian

Markavian
Total Posts: 11
Joined: January 14, 2012

My problem: The Android version code needs to be incremented to publish a new version of an APK file to the Google Play App Store.
This problem: NME hardcodes the version code and version name into AndroidManifest.xml

Prereqs: Signing your APK file
http://www.gigglingcorpse.com/2012/03/15/nme-signing-for-android-re...
(Thanks for this great post, I had to downgrade to JDK 1.6_r30 after my APKs failed to sign correctly, just as you said.) - Solves issue with missing Certificate File after NME signing process completes.

Changing version code:
NME already does a fantastic job compiling and signing APK files for distribution, but one problem I faced over the last few nights was changing the version code to replace an APK file with an erronous certificate file. The problem is that the NME build tool hardcodes the version code and version name into the AndroidManifest.xml file before building and signing. The default values are 1 and 1.0. The code is an incremental value, while the name is a descriptive version string.

I have found two solutions to this problem:

Solution 1: Import generated code into Eclipse, and build yourself
Thanks to mi6_x3m for helping me set this up, I've never used Eclipse for Android builds before.
In the {nme project}\bin\android\bin directory are all the files for the Android build, which are compatible with Eclipse for Java developers, with Android Development Tools installed.
I had to use File -> New Android Project -> Create project from Existing Source to import the files, and there were a few errors about @Override functions, which I fixed by removing the overrides... but this enabled me to build the project.
I then edited the AndroidManifest.xml file through Eclipse, and built and signed a working APK file.

Solution 2: Modify NME command-line tools
Truth be told, I don't like booting up eclipse, when NME does almost everything already.
So, by building NME from source I was able to figure out how to pull values from my application.nmml file through the AndroidManifest.xml file.

I'll just quickly overview the changes I made to the code base to create an automated process:

The template for AndroidManifest.xml already contains some template variables, namely: ::ANDROID_INSTALL_LOCATION::. I added two new variables: ::ANDROID_VERSION_CODE:: and ::ANDROID_VERSION_NAME:: to this file.

I added default values for these in InstallerBase.hx:
setDefault ("ANDROID_VERSION_CODE", "1");
setDefault ("ANDROID_VERSION_NAME", "1.0");

In the same file, I added a switch case in parseXML:
case "android":
parseAndroidElement (element);


And a new function:

private function parseAndroidElement(element:Fast):Void {
for (attribute in element.x.attributes ()) {
switch (attribute) {
case "version-code":
defines.set ("ANDROID_VERSION_CODE", substitute (element.att.resolve ("version-code")));

case "version-name":
defines.set ("ANDROID_VERSION_NAME", substitute (element.att.resolve ("version-name")));

default:
defines.set ("ANDROID_" + attribute.toUpperCase (), substitute (element.att.resolve (attribute)));
}
}
}


These are all the code changes that bring XML values from the NMML file through to the build system, to make values available in AndroidManifest.xml. From here I built the command line tools again (haxe CommandLine.hxml from nme/tools/command-line/).

The final step was to add an XML tag to my application.nmml file, e.g.:
<android version-code="4" version-name="1.0.2 R2" />

Publishing an APK file:
I have trouble finding site, so here's the link-
http://play.google.com/apps/publish/
Sign in with a google account and follow google's instructions:

A new APK file with an updated version code can be uploaded to replace an existing one.

I hope that helps people! I'm off to publish some more mini-projects to google play : )

- Markavian

Tags:
Posted on April 25, 2012 at 4:41 PM

singmajesty

singmajesty
Total Posts: 2139
Joined: August 25, 2011

Re: Changing the Android Version Code for the Goole Play App Store

I was just thinking this morning that I was going to need something like this, as I noticed the same when I tried to sign the same version of an application for BlackBerry for the second time.

So would the ideal for the "version ID" be the version number, plus a build number, like "1.0.0.1000" and then the "version name" would be the traditional version from your NMML file? Or does the version ID have to be an integer?

I was thinking about saving a ".build" (or similar) file in your output directory, and using this to increment a build number each time you compile. Then for issues like these, would could automatically use some sort of APP_BUILD_VERSION value in these project templates.

What do you think?

Posted on April 25, 2012 at 4:46 PM

Markavian

Markavian
Total Posts: 11
Joined: January 14, 2012

Re: Changing the Android Version Code for the Goole Play App Store

Yeup, that sounds great singmajesty, I wasn't sure how to reuse the version code in the app field. Looking at the code I guess it would be APP_VERSION, and then like you say, an additional number would be needed for the android:versionCode field. If a .build file is easy to set up, then that'd be great for version tracking.

Edit: I think having one common field for version / version code that gets built to all devices is best, it would probably be more effort all round to have special cases for each platform - unless a specific platform required the version numbers to say the same (?).

Posted on April 25, 2012 at 4:53 PM

altef

altef
Total Posts: 105
Joined: February 25, 2012

Re: Changing the Android Version Code for the Goole Play App Store

Hi,

This is only vaguely related, so feel free to ignore. Just wanted to note that a third option (the one I used) was to overwrite AndroidManifest.xml with your own, using the template tag in your nmml file.

It's really easy to do, and there's an example at the bottom of this post if you're interested: http://www.gigglingcorpse.com/2012/03/22/programming-for-android-in-java-but-using-nme/

(Also, it sounds like this will become moot in the near future, which is awesome.)

Posted on April 25, 2012 at 8:12 PM

singmajesty

singmajesty
Total Posts: 2139
Joined: August 25, 2011

Re: Changing the Android Version Code for the Goole Play App Store

This is fixed on SVN.

NME now increments build numbers automatically (by maintaining a ".build" file in your output directory), which applies to the "android:versionCode" attribute.

You can also override this yourself (if needed) by setting <meta build-number="" />

Posted on April 26, 2012 at 1:36 PM

singmajesty

singmajesty
Total Posts: 2139
Joined: August 25, 2011

Re: Changing the Android Version Code for the Goole Play App Store

If your NMML has <meta version="1.1.0" />, and you've compiled your application (for any target) a total of 12 times, the "android:versionName" attribute will equal "1.1.0", and the "android:versionCode" attribute will equal "12"

I have not tested Android signing, but this resolved issues with release-signing for BlackBerry, when trying to sign the same application version a second time smiling

Posted on April 26, 2012 at 1:38 PM

Markavian

Markavian
Total Posts: 11
Joined: January 14, 2012

Re: Changing the Android Version Code for the Goole Play App Store

Hey signmajesty, just tested the new functionality, works great. smiling

- M

Posted on April 26, 2012 at 4:23 PM

Huge

Huge
Total Posts: 546
Joined: October 07, 2011

Re: Changing the Android Version Code for the Goole Play App Store

Hi,
I am not sure about a ".build" file. My main question, is "is it precious" or "is it throw-away".
Do you put it in SVN/CVS/GIT/HG or do you leave it lying around on your disk, to be thrown out at some stage?
When you release your code, and have a user go "I have a bug in version 12345", do you *exactly* what they are referring to?
If it is precious, it should not be in a hidden file. If it is submitted, it should be getting its version from the RCS version number,
Other options, may be - date/time: 201204271427
Or, probably better, simply convert the version to an integer:

1.1.2 -> 10102

Some possible syntax:

<app version="1.0.1" codeVersion="12345" />
<app version="1.0.1" codeVersionSource="version" />
<app version="1.0.1" codeVersionSource=".build" />
<app version="1.0.1" codeVersionSource="svn" />

While the .build syntax might work for you, I do not think that it is a "best practice".

Hugh

Posted on April 27, 2012 at 12:58 AM

singmajesty

singmajesty
Total Posts: 2139
Joined: August 25, 2011

Re: Changing the Android Version Code for the Goole Play App Store

This was my line of thinking:

1.) I don't like creating lots of extra files, and "messing up" the workspace
2.) I'm nervous, though, of modifying the user's NMML file. What if something goes wrong?
3.) What's the right solution for version control?

If we update the NMML file, you're going to be committing it into version control every time. Maybe that's alright, but I imagined it could be a pain, because it would be hard to track "real" changes to your project, instead of the normal incrementing for builds.

One of the problems I had when I added release-signing for BlackBerry is that I could not release-sign the same application version more than once. I realized that if the application version remains the same, but the build number changes, then I can sign it. For this reason, I think the build number needs to be based on how many times you build, not on the meta-data. If I set up my project to release-sign, then the moment I hit build, I'll have used up that identifier. Unless I were to modify my NMML, then next time I build the server would refuse my request, since that application version / build number had already been signed before.

For that reason I think it also needs to be separate from the revision from your source control, if you're using a versioning system. We actually do need build numbers, and not just revision numbers.

So with all this said, the solution seems to be to write and increment a value somewhere. Unless, that is a good suggestion -- unless it were based on the date. You could have weird issues with different clocks or timezones, but generally that would be a good system for generating build numbers without writing to a file.

I don't think that something tricky like file attributes (or something weird) would make sense, so that's why I settled on the .build file. We could use "build" instead of ".build", or we could update the NMML if that seems like a better way to go, or...? I'm totally open to making adjustments to help this feel comfortable and reliable long-term. You do make a good point that this should probably be saved in version control, and hiding the file will probably prevent that from happening by default

Posted on April 27, 2012 at 1:38 AM

Huge

Huge
Total Posts: 546
Joined: October 07, 2011

Re: Changing the Android Version Code for the Goole Play App Store

Hi,
Well, if you only need it for developing, then a .build file should be ok - you can can always trash it and uninstall your app from the device and start again.
But for something you submit to an app store, I think you want a "real" number from a build system, or generated from the version number stored in the nmml file.
I agree you should not be changing the nmml file from the script.

We might need some kind of "build for app store" flag, which disables traces and maybe completely deletes the bin directory before going on. If you do this a couple of times, you might need to uninstall from the device for re-testing, but I think this is OK (in fact, good practice) for a "final" release.

Hugh

Posted on April 30, 2012 at 12:16 AM