I am trying to modify my gradle file to allow for different names for my app based on Flavor and Build Type. So far, I have been successful in being concise with Flavor based naming using Manifest Merging techniques via the Android Gradle Plugin Docs
Current
These are the names of the applications on my home screen for both my debug and release builds.
Flavor Debug App Name Release App Name
-------- -------------- ----------------
entity_1 App Name App Name
entity_2 App Name App Name
... ... ...
entity_2 App Name App Name
hub Hub Hub
Its's close, but...
Desired
Flavor Debug App Name Release App Name
-------- -------------- ----------------
entity_1 App Name - Entity_1_name App Name
entity_2 App Name - Entity_2_name App Name
... ... ...
entity_n App Name - Entity_n_name App Name
hub Hub Hub
I want this so I know which debug flavor is which on my home screen. I don't care about differentiating on the release flavors as a user will only have one on their device (it might be possible to have more than one, but I am not concerned with that)
Given how extensible Gradle is, I assume this is possible; however, I am not an advanced Gradle user.
So, how can I concisely (as possible) extend my code to get to my desired output?
Note: the above tables use versionNameSuffix as a suffix for my app name; however, it can be anything (another added variable??) that will allow me to tell which flavor I am using only in my debug build type.
Non-goals
Not interested in
String Resourcesolutions as in the answer to Android/Gradle: App name based on build type *and* product flavor. A pure Gradle based solution is preferred.Not interested in going away from the
Manifest Mergermethod that I have currently implemented. The answer at https://stackoverflow.com/a/28465883/2333021 is another way of implementing what I have already done, and does not allow me to only do this on the debug build (that I can see. If it does, then let me know).
Code
android {
compileSdkVersion 23
buildToolsVersion "23.0.2"
defaultConfig {
applicationId "..."
minSdkVersion 17
targetSdkVersion 23
versionCode 1
versionName "1.0"
manifestPlaceholders = [ applicationLabel:"App Name"]
}
productFlavors {
entity_1 {
versionNameSuffix ' - Entity_1_name'
applicationIdSuffix 'entity_1'
}
entity_2 {
versionNameSuffix ' - Entity_2_name'
applicationIdSuffix 'entity_2'
}
hub {
versionNameSuffix ' - Hub'
applicationIdSuffix 'hub'
manifestPlaceholders = [ applicationLabel:"Hub" ]
}
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
Manifest
<manifest ...>
<application
...
android:label="${applicationLabel}"
... >
Update
android {
compileSdkVersion 23
buildToolsVersion "23.0.2"
ext {
APP_NAME = "App Name"
HUB_NAME = "Hub"
}
defaultConfig {
applicationId "..."
minSdkVersion 17
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
productFlavors {
one_million {
versionNameSuffix ' - Entity_1'
applicationIdSuffix 'entity_1'
manifestPlaceholders = [ applicationLabel: APP_NAME + versionNameSuffix ]
}
udacity {
versionNameSuffix ' - Entity_2'
applicationIdSuffix 'entity_2'
manifestPlaceholders = [ applicationLabel: APP_NAME + versionNameSuffix ]
}
hub {
versionNameSuffix ' - Hub'
applicationIdSuffix 'hub'
manifestPlaceholders = [ applicationLabel: HUB_NAME ]
}
}
buildTypes {
release {
manifestPlaceholders = [ applicationLabel: APP_NAME ]
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
New Output
Flavor Debug App Name Release App Name
-------- -------------- ----------------
entity_1 App Name - Entity_1_name App Name
entity_2 App Name - Entity_2_name App Name
... ... ...
entity_n App Name - Entity_n_name App Name
hub Hub App Name <- Issue (Release)
The first try was a closer solution to the right answer than the updated code.
Further refactoring could possibly done by moving all the
manifestPlaceholderscode inside theapplicationVariants.allsection; however, this is a working copy of a semi-clean, gradle-only solution...Notes:
BEFORE the
applicationVariants.all { ... }code runs, this is what all the applicationLabel look like. We are close, but need to ADD to them...AFTER the
applicationVariants.all { ... }code runs, this is what all the applicationLabel look like. We are done!Also...
defaultConfigdoes not have a way of accessing information within the individualproductFlavors. AlthoughdefaultConfigis aFlavorkind of, only the specifiedFlavorscan read information from within thedefaultConfig. There are no mechanism to go the other way (that I am aware of). So you need to set the most generic type in thedefaultConfigAny information within the
buildTypesblock will get the final say, and the code withinapplicationVariants.allwill not override that. In order to overcome that, you have to remove the needed code from thebuildTypeblock and move it within theapplicationVariants.allblock (with the correct logic statements)