Using an ‘Unusual’ Timestamp as an Auto-generated Version Code for Android Apps

You might encounter an error of conflicting version code when you try to automate a deploy process for an Android application. You’re reading this post, and I’m writing this post. It means that we experienced the same problem, mate!

Google Api Error: apkUpgradeVersionConflict: APK specifies a version code that has already been used.

According to the official document, we can use any positive number and don’t have to increase the number sequentially. At first, I was going to use Unix time as a version code, but I changed my mind after I read this warning.

Warning: The greatest value Google Play allows for versionCode is 2100000000.

Fair enough, this is a limitation of a 32bit signed-integer. However, it means my versioning system will expire at 18 July 2036. Is it the far future for a personal app? Everything will change in 18 years? I think so, but if we can avoid this problem easily, it’s better!

Two popular approaches

Fortunately, there are a lot of people who have the same problem. I found two solutions to solve this.

One of the solutions is to use a saved number for the version code. Read it from a file or storage, increment it, and write it back. It produces a clean version code, and this is quite easy to understand. I thought it’s a good idea since I like a simple solution, but I don’t like making a dependency to an external file.

Autoincrement VersionCode with gradle extra properties

Another solution is to calculate a version code from the version name. For example, majorVersion * 10000 + minorVersion * 100 + patchVersion. We have enough digits to apply this method. It’s also simple, practical, and no dependency! However, I decided not to use this because I don’t want to change the version name for each deployment. Especially for internal test track, I’d love to deploy my beta app with just changing the code itself.

Manage your Android app’s versionCode & versionName with Gradle

Just postpone the expiration date

As a result, I took a very simple way. I just postponed the expiration date until 19 June 2635! This date comes from 2100000000 * 10. Yes, I just used a Unix time divided by 10 as a version code. All I had to do is calculating it in CI,

set_version_script:
  - U=$(expr $(date +%s) / 10) # increase by 1 in each 10 seconds
  - echo "versionCode=${U}" >> version.properties

and reading it in build.gradle.

defaultConfig {
    ...
    versionCode versionProperties['versionCode'].toInteger()
    ...
}

It works well because deployments happen not so frequently and I believe everything will change in 600 years!

Conclusion

I’m using a Unix time divided by 10 as a version code. It’s feasible, easy to implement, and developer-friendly for a small app.

Thanks reading! If you have any other ideas, please comment to this post.