Utilize Android App Version Names and Suffixes
Defining semantic versions via versionName and versionNameSuffix in defaultConfig, buildTypes and productFlavors
Versioning in Android is critical to identifying capabilities and age of the application. Like many other software components, Android applications are automatically handled by services (such as the CI) or manually managed by persons (such as the QA or PO). While the Android system uses a simple numerical versionCode to protect against downgrades of applications, services and persons mostly rely on the versionName defined for the application. This versionName can be any string and the Android system doesn’t enforce any constraints on it. For human and machine readability, Semantic Versioning should be considered though.
The versionName is part of the Android manifest, but it’s usually defined for all build variants within the build.gradle script of the application. Here it’s possible to declare a versionCode, a versionName and a versionNameSuffix.
defaultConfig {
versionCode 123
versionName '1.2.3'
versionNameSuffix '+default'
}buildTypes {
debug {
versionNameSuffix '.debug'
}
}flavorDimensions 'app', 'env'
productFlavors {
free {
dimension 'app'
versionNameSuffix '.free'
} staging {
dimension 'env'
versionNameSuffix '.staging'
}
}
The given Gradle build file generates a final version name with the versionName concatinated with all provided versionNameSuffix values. These values are selected starting with the default config, followed by all product flavors in order of their flavor dimension position and ending with build type.
1.2.3+default.free.staging.debug
The versionName property is only available for the default config and any product flavor. The flavor dimensions define the version name in order of their dimensional position. The value defined with the default config is the fallback for when no other versionName was defined.
Depending on the process and environment, the app version could differ for CI builds or product flavors that are only used internally and not meant to be released. With the proper setup and a meaningful Semantic Versioning applied to it, these versions are a useful tool for any release process and every person involved in managing the application.
