And, why would I want something like that? you may ask yourself.
Well, let’s start answering that question with another one. Are all apk’s you generate the same? Of course, not. Application name (aka versionName) uses to refer to a concrete version of the app, like 2.3, 13.1.0_2342, 42.2-build.4424 or whatever. This could be fair enough for a release, but meanwhile the app is on a development process, application name should provide a bit more information.
I found this approach really useful in my team, since each team member is working on a different feature, the application will be renamed based on the feature, so any build can be identified by stakeholders, such as testers, product owners or in our continuous integration system.
Custom gradle plugin
As an Android developer we apply several gradle plugins daily, for example com.android.application is the gradle plugin for Android app builds. Plugins will manipulate and extend our build process to follow some conventions or to provide a specific configuration. In fact, this is what we want, modify default build process to change app versionName.
There are 3 different ways of creating a gradle plugin (here you can check documentation), but we are going to choose buildSrc folder one, mainly because it is easy to create and it will be included in your repository. On the other hand, plugin will be attached to your project, and it cannot be reused.
First of all we need to create proper folder structure to let gradle compiling buildSrc folder code. Notice, after sync, gradle will understand groovy folder, and it will be marked as so . Thus, build process will compile every source code inside this folder.
We will also create plugin file (CustomPlugin.groovy) below a desired package folders. The main purpose of the plugin will be to create a gradle task, which actually is going to be responsible of changing app versionName, and add it to the task hierarchy. Before coding the plugin we are going to create gradle task which actually will modify app name.
As you may know, a task is an atomic piece of work in the build process. In next step we will create a custom task which takes android build variants and changes versionName property.
As any task, we need to extend it from DefaultTask and it forces us to create default run() method.
Let's see how task looks like.
NOTE: This task only adds custom suffix to versionName, but here you can rename to whatever convention you want. I will give you an example later.
We already designed task to modify versionName of the app, so now it is time to implement gradle plugin and include our new task to build dependencies.
Since Android build includes versionName info in the app, we must define task dependency in order trigger it before Android build starts. There is a gradle task named preBuild which is perfect to accomplish this requirement.
Plugin is ready to be used.
Once we have the plugin created we can apply it to our Android application module (or even Android Library module).
Just include the apply statement in app build.gradle file like any other plugin.
apply plugin: CustomPlugin
Bonus: Renaming by git branch
As you saw, gradle task just adds a suffix to app version name, but we can update it to any desired naming convention.
As an example, in my team we are working with git following gitflow. This means that we are creating a branch for each feature in the development process. Furthermore, branch name is based on a convention which prefix the id of the feature (Jira issue id in this case).
Task will take branch name, extract feature id and add it to versionName.
At the end of the day, we can identify builds by the app name, and determine which feature is related to, for example, in Fabric Beta or in test devices. With names like 2.3_P-23 or 4.1.2_P-292 is much easier to know what we are talking about.