Releasing an app update on Google Play

Briefly recording my workflow for releasing an update for the Commons app on Google Play (lest I forget!):

  1. Submit pull request with my changes to project maintainer. Wait for merge.
  2. After pull request accepted, do versioning and tagging
  3. Record changes in file
  4. Generate a signed APK using the keystore file, keystore password, key alias (auto generated by IntelliJ) and key password
  5. Upload new APK to Google Developer page and copy over changelog to be shown to users
  6. Wait several hours for the update to go through, then check app to see if it works as intended
  7. Do git rebase upstream/master to update my repo based on the upstream repo without creating messy merge commits. Check what the upstream repo is via git remote -v if there are errors with this.
Releasing an app update on Google Play

Versioning and tagging

The project maintainer of the open source Android app that I’m contributing to (Upload to Commons) has given me developer access to the app on Google Play! Exciting stuff. 😀 While I’ve tinkered with Android before, none of the apps I made have ever made it to the store. I don’t think I’ve even paid for a publisher account yet (note to self: this must be remedied in the future).

I’ve learnt real quick that maintaining a live app on Google Play is quite different from just tinkering on an app that isn’t in use by real people! The user base for this app is currently still small, so fortunately there’s no need for running a beta test and such. But one of the things it does require is managing the version so that the updates make sense and are tidy. There are two places this needs to be done…

The Android Manifest

In the <manifest>  element of the AndroidManifest.xml file, the values that need to be changed are:


The android:versionCode attribute is the internal version code that isn’t displayed to the user, and is used to determine which version is more recent, so we just increment this by 1 for each successive version. The android:versionName attribute is used solely to display the version to the user, and in our case we will increment it by 0.1 for each successive version.

Tagging the relevant commit in Git

I found a useful blog post on the use of git tag.

Basically, I go into the shell (yup, this has to be done via command line AFAIK) and, if I want a lightweight tag, type

git tag v1.3

If I want an annotated tag, I’ll type

git tag -a v1.3 -m "Version 1.3"


Tip of the day: Found out from my mentor that adding ?w=1 to the end of the URL for a particular commit on GitHub (e.g. makes it ignore the file changes that just involve whitespace! Whew.

Versioning and tagging