Managing app versioning in Android Studio - simplifying versionCode, versionName, and versionNameSuffix

Versioning is an important aspect of any mobile app development process. In Android, this is handled through versionCode and versionName, which allow you to define the current state of your app for users and the Play Store. But where exactly should these be managed, and how can you ensure they propagate correctly across your project? This article covers the essentials of managing app versioning in Android Studio, using the build.gradle file.

Where is the versionCode and versionName managed?

In earlier Android development workflows, developers would manage android:versionCode and android:versionName directly within the AndroidManifest.xml file. However, the more modern and preferred method is to manage these properties in the build.gradle file, located within your app’s module directory.

For example:

android {
   compileSdkVersion 33
   defaultConfig {
       applicationId "com.example.app"
       minSdkVersion 21
       targetSdkVersion 33
       versionCode 24  // Your app's version code
       versionName "3.0"  // Your app's version name
   }
}

In this configuration, the versionCode is an integer value used to identify different builds. The versionName, on the other hand, is a string that’s displayed to users. Managing these in the build.gradle file centralises control and reduces the risk of mismatched version information.

How does versionNameSuffix work?

Android Studio also offers a handy feature called versionNameSuffix, which allows you to append a suffix to the versionName. This is particularly useful when you're creating build variants for different environments, such as production, beta, or development builds.

For example, you can define your versioning like this:

versionCode 24
versionName "3.0"
versionNameSuffix ".9"

This setup will generate a full version name of 3.0.9, combining the base versionName (3.0) with the versionNameSuffix (.9). You can easily differentiate between different builds of the same version, whether you’re preparing a beta release or a final production build.

How Android Studio applies these values to the AndroidManifest.xml

Now that you know where to manage your versioning, you might wonder how these values are applied to your AndroidManifest.xml file. The good news is that Android Studio automatically merges these values into the final AndroidManifest.xml file during the build process. There’s no need to manually update multiple manifest files for different build variants.

To confirm that the versioning has been correctly applied, you can check the generated AndroidManifest.xml in the build output. After building your app, navigate to app/build/outputs and find the manifest file. You’ll see that the version information from your build.gradle file has been merged, resulting in something like this:

<manifest ... >
   <application ... >
       ...
   </application>
   <uses-sdk ... />
   <meta-data
       android:name="android:versionCode"
       android:value="24" />
   
   <meta-data
       android:name="android:versionName"
       android:value="3.0.9" />
</manifest>

This ensures that the versioning for your app is consistent across different environments and builds.

The wrap

By managing versionCode, versionName, and versionNameSuffix in the build.gradle file, Android developers can streamline their workflow and avoid potential version mismatches. The automated merging of this data into the AndroidManifest.xml simplifies the process, ensuring that your app is correctly versioned and ready for distribution, whether you’re pushing a development build or a production-ready release.