Update: there’s a new version of this build script
Android apps require not one, but two version numbers:
- Version code: an integer that Android uses to check whether one version is more recent than another
- Version name: a friendly version to display to the user, conventionally something like 1.2.3
This means that when you want to build a new release of your app, you have two things to manually update, and that is two things too many. You will make mistakes.
Luckily, it’s not too hard to automate this away in your Gradle build script.
Gradle inherited much of its design from Apache Maven. Maven defined a standard release feature that automatically handles typical pitfalls and mindless details of making a release: tagging in source control and incrementing your version number. For Gradle, there is a nice third-party implementation, the gradle-release plugin. So long as you don’t fight Maven-style version conventions, it can make cutting releases almost entirely automatic, modulo prompting you to confirm that it guessed correct version numbers.
If your project only has one version number, you just apply the release plugin and you’re done, but Android’s two-version-number system takes some customization.
I only discuss version numbers here, but the release plugin also does several other useful sanity checks.
First, move the versions out of your app/build.gradle into app/gradle.properties. They should look like so:
app/gradle.properties
version=1.0-SNAPSHOT versionCode=1
app/build.gradle
android {
// ...
defaultConfig {
versionCode project.versionCode.toInteger()
versionName project.version
// ...
“SNAPSHOT” is Maven’s convention for “between releases”. Version 1.0-SNAPSHOT means the code leading up to version 1.0. This convention is how the release plugin guesses what version number you are releasing: it just lops off the suffix.
When you run ./gradlew release, the release plugin updates the version thus:
- Edits gradle.properties, removing the “snapshot” part
1.0-SNAPSHOT becomes 1.0 - Commits the change and tags this as version 1.0 in source control
- Builds the release
- Edits gradle.properties again, to next dev version
1.0 becomes 1.1-SNAPSHOT - Commits so you can immediately start working on version 1.1
Thus, out of the box, this handles the user-friendly version number, but not the “version code.”
Updating the version code
When Android installs an update to an app, it knows by version code whether the update is newer than what it currently has installed. 3 is newer than 2 and so on.
Thus, the obvious strategy for updating your version code is to add one on every release. If using the release plugin, you might do this as a manual step after it finishes a release. If you forget, you’ll accidentally build your next release with the same version code as you just used. If you have other branches, you need to remember to update them as well. Ouch.
There is a better way. Version codes need not be sequential, so instead of incrementing 1,2,3…, we can derive it from the date. A format like [2-digit year][month][day][0-9] works nicely. A release today gets version code 1704080, tomorrow, 1704090.
This format will cover you for 82 years at up to ten releases a day. If that’s not enough for you, use a four-digit year and a two-digit suffix, but watch out for integer overflow in 130 years or so.
The date-based strategy, however, means that you have to set your “version code” immediately before you release, instead of after. To do this, add a Gradle task right before updating version name.
app/build.gradle
task setVersionCode { doLast {
// Add a task that updates version code
def current = project.versionCode.toInteger()
def releaseAs = new Date().format('YYMMdd0', TimeZone.getTimeZone('UTC'))
if (releaseAs.toInteger() <= current) {
// More than one release today
releaseAs = current + 1
}
def releaser = project.plugins[net.researchgate.release.ReleasePlugin]
def propsFile = releaser.findPropertiesFile()
def props = new Properties()
propsFile.withInputStream { props.load(it) }
props.versionCode = releaseAs.toString()
propsFile.withOutputStream { props.store(it, null) }
}}
// Execute our task before unSnapshotVersion, provided by the release plugin:
unSnapshotVersion.dependsOn setVersionCode
With this simple build script change (plus applying the release plugin), a single command updates both version numbers:
./gradlew release
The release plugin also runs the “build” task at the point of release, so this single command leaves you with both a release .apk and your working directory updated to the tip (snapshot) code ready to start work on the next release. There’s still a problem though: if you haven’t configured your build script to sign the build, you won’t be able to publish the release .apk.
Signing the build
To make Gradle sign a build, you need to add a “signingConfig”:
android {
// ...
signingConfigs {
release {
storeFile file('/home/myname/.javakeys/mykeys.jks')
keyAlias 'myappsigningkey'
// These two lines make gradle believe that the signingConfigs
// section is complete. Without them, tasks like installRelease
// will not be available! (see http://stackoverflow.com/a/19350401)
storePassword "notYourRealPassword"
keyPassword "notYourRealPassword"
}
}
buildTypes {
release {
signingConfig signingConfigs.release
// ...
This fails, so you put your real password in the “password” config place and get pwned. Your wife leaves you, and your dog dies. You didn’t do that, right?
So where should you put your password? The top-voted answer on Stack Overflow says ~/.gradle/gradle.properties, presumably protected by 600 permissions. I don’t see the point. If you’re relying on file system permissions to keep the password secure, why have the password at all? You could just protect the keystore with file system permissions.
What you need is a prompt for the password.
Thanks to bug 1251, Gradle running in daemon mode (the default) doesn’t let you use System.console().readPassword("Password:"). You can disable daemon mode, but then you run afoul of (orphaned?) bug 2357 because Android Studio generates a default gradle.properties that includes jvmargs. Once you remove that configuration, you find that prompts don’t display when you build not in daemon mode (bug 869). That’s a pain because you can’t see the version number confirmation prompts.
As a result of this epic adventure, you’ll eventually find that the only reliable way to prompt for password is via Swing. No, I’m not joking. It’s not as gruesome as it sounds, thanks to Groovy’s Swing builder, so pop over to where Tim Roes documented how to do it.
Should Be Simple 