Android App Build Numbers Must Always Be Greater Than Previous Versions
As the title suggests.
The Problem
Recently, I changed the way I set the build number for a Flutter-based Android app to use the commit count.
Setting the Build Number Based on Commit Count When Building a Flutter App on GitHub Actions
Excited, I built the app and tried to submit it for review on Google Play, only to encounter the following error:
##[error***You cannot rollout this release because it does not allow any existing users to upgrade to the newly added APKs.The Cause
After some investigation, I discovered, as the title of this article suggests, that the build number for Android apps must always be greater than previous versions.
versionCode - A positive integer used as an internal version number. This number is used only to compare versions to determine which one is newer. The larger the number, the newer the version. This number is not visible to users. The number displayed to users is defined by the versionName setting below. The Android system uses the versionCode value to prevent downgrades, so users cannot install an APK with a versionCode lower than the one currently installed on their device.
Solution
I had already released versions 1.0.0~1.0.3, with build numbers ranging from 10000~10003.
This meant that the build number for future releases had to be greater than that.
To resolve this, I decided to set the build number to commit count + 10000. Although it feels a bit messy, it’s the consequence of not handling build numbers properly from the beginning.
Finally, the part of the GitHub Actions workflow where the build number is set ended up like this:
VERSION=$(cider version)
GIT_COMMIT_COUNT=$(git rev-list HEAD --count)
BUILD_NUMBER=$(($GIT_COMMIT_COUNT + 10000))
cider version $VERSION+$BUILD_NUMBERConclusion
The lesson here is: “Decide how to manage build numbers properly before the initial release.”
