I'm using buildTypes and productFlavors. My app also uses an analytics tool and this tool used the versionName of my app.
How can I change the versionName per flavor? My test was
productFlavors {
google {
versionNameSuffix ".google"
}
}
but it failed. Does anybody has an idea how to custom the versionName depending on the flavor?
Update
Apparently the 2.2.0 version of Gradle Android plugin now allows setting versionNameSuffix in productFlavors
This is still a work in progress for me, but seems to work:
productFlavors {
development {
versionName = android.defaultConfig.versionName + (System.getenv("BUILD_NUMBER") as Integer ? "-build" + System.getenv("BUILD_NUMBER") as Integer : "-developerBuild")
}
}
So we can set the versionName in defaultConfig, on the build server it sets the environmental variable BUILD_NUMBER, so ends up being like: 1.2-build1234 The production build only uses the defaultConfig so is just 1.2, and when building on dev machines the environmental variable isn't set so its 1.2-developerBuild
Just came up with this plan tonight (so could be simplified i'm sure), so working on getting the latest source control revision added when on a dev machine, but i've seen other answers with how to do that.
You can set the entire version name through a flavor, like this:
productFlavors {
flavor_a {
versionName 'Version_A'
}
flavor_b {
versionName 'Version_B'
}
}
defaultConfig {
versionName 'Default_version_name'
}
If a flavor doesn't specify a version name, it will pick it up from defaultConfig.
Related
Is it possible to change the package name of an Android application using Gradle?
I need to compile two copies of the same app, having a unique package name (so I can publish to the market twice).
As a simpler alternative to using product flavours as in Ethan's answer, you can also customise build types.
How to choose between the approaches:
If you need different package names to be able to have both debug and release apks installed on a device, then use the build type approach below, as Gradle plugin docs agree. In this case flavours are an overkill. (I think all projects should by default do this, as it will make life easier especially after you've published to the store and are developing new features.)
There are valid uses for product flavours, the typical example being an app with free and paid versions. In such case, check Ethan's answer and read the documentation too: Configuring Gradle Builds and Gradle Plugin User Guide.
(You can also combine the two approaches, which results in every build variant having distinct package name.)
Build type configuration
For debug build type, and all other non-release types, define applicationIdSuffix which will be added to the default package name.
(Prior to Android Gradle plugin version 0.11 this setting was known as packageNameSuffix.)
android {
buildTypes {
debug {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
}
beta {
applicationIdSuffix '.beta'
versionNameSuffix '-BETA'
// NB: If you want to use the default debug key for a (non-debug)
// build type, you need to specify it:
signingConfig signingConfigs.debug
}
release {
// signingConfig signingConfigs.release
// runProguard true
// ...
}
}
}
Above, debug and release are default build types whose some aspects are configured, while beta is a completely custom build type. To build the different types, use assembleDebug, assembleBeta, etc, as usual.
Similarly, you can use versionNameSuffix to override the default version name from AndroidManifest (which I find very useful!). E.g. "0.8" → "0.8-BETA", as configured above.
Resources:
This example is straight from Xavier Ducrohet's "Google I/O 2013: The New Android SDK Build System" presentation.
Build Types in the User Guide.
Myself I've been using productFlavors so far for this exact purpose, but it seems build type customisation may be closer to my needs, plus it keeps the build config simpler.
Update (2016): I've since used this approach in all my projects, and I think it definitely is the way to go. I also got it included in Android Best Practices guide by Futurice.
You could so something like this
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor1", "flavor2"
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
You can also change the field android.defaultConfig.applicationId if you want to do one-off builds.
Taken from: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration
With the gradle plugin version of 1.0.0+ you have to use applicationId as stated in the migration guide
Renamed Properties in ProductFlavors
packageName => applicationId
Thus in your build.gradle you would now use:
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
}
flavor2 {
applicationId "com.example.flavor2"
}
}
From Ethan's answer, both flavorGroups and packageName both are not available anymore. Below works as of March 2015.
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor"
productFlavors {
flavor1 {
flavorDimension "flavor"
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
flavorDimension "flavor"
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
I did not want to use Flavors, so I found a way to do so with buildTypes. I did this by changing my app/build.gradle file as follows:
defaultConfig {
applicationId "com" // See buildTypes.type.applicationIdSuffix
...
}
...
buildTypes {
debug {
applicationIdSuffix ".domain.name.debug"
...
}
releaseStaging {
applicationIdSuffix ".compagny.staging"
...
}
release {
applicationIdSuffix ".domain.name"
...
}
}
This allows me to have 3 apps next to each other on my devices.
I hope this helps others.
I am currently developing my first Android application ever, and it is the Android/Kotlin version of an iOS application I already developed. I created 3 different Firebase projects to have independent realtime database instances for each environment:
com.myapp.debug is only used by me for development
com.myapp.beta should be used for alpha and beta testing
com.myapp should be only for the production application that will be released publically on the Play Store
When I was looking into plugging these 3 environments in my Android app, I read that I should use product flavors for that, so here is how I configured my build:
android {
compileSdkVersion 27
defaultConfig {
applicationId "com.derbigum.approofreferences"
minSdkVersion 15
targetSdkVersion 27
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
flavorDimensions "dev", "qa", "prod"
productFlavors {
dev {
dimension "dev"
applicationId "com.derbigum.approofreferences.debug"
}
qa {
dimension "qa"
applicationId "com.derbigum.approofreferences.beta"
}
prod {
dimension "prod"
applicationId "com.derbigum.approofreferences"
}
}
}
And of course I created the corresponding subfolders in src to store the various versions of google-services.json I got for each project.
I did all my development with that and it worked so far: development data was created in the right database.
But now I want to do a first closed alpha release but I'm confused as to how I should generate my APK. I have only 2 build variants:
devQaProdDebug
devQaProdRelease
Maybe I made a mistake in configuring flavorDimensions? Maybe it's something else. Can someone please help me figure out if my setup is OK, and if so how I should go about building the closed alpha version of my app and release it to my internal users for testing?
I think what you want here is not three dimensions for three environments, but just one dimension for environment, with three flavors:
flavorDimensions "env"
productFlavors {
dev {
dimension "env"
applicationId "com.derbigum.approofreferences.debug"
}
qa {
dimension "env"
applicationId "com.derbigum.approofreferences.beta"
}
prod {
dimension "env"
applicationId "com.derbigum.approofreferences"
}
}
This will get you build variants for each environment.
When I try to deploy with these productFlavors, wear debug apk won't built and it is not embedded into mobile release apk. But after I delete productFlavors from mobile and wear build.gradle file, it's working as it should.
productFlavors {
lite {
}
pro {
applicationId 'example.app.id.pro'
versionNameSuffix '.pro'
}
}
Try assigning applicationIdSuffix and versionNameSuffix values for each of your product flavors. See Configuration of Product Flavors for more information.
And if you haven't done yet, add publishNonDefault truein your Wear module's build.gradle file.
android {
publishNonDefault true
......
productFlavors {
trial {
applicationId "com.sample.myapp.trial"
versionName "3.0.1"
versionCode 301
}
full {
applicationId "com.sample.myapp"
versionName "3.0.1"
versionCode 301
}
}
}
See this related SO post and Packaging and Distributing Wear Apps for additional insights.
I want to change the app versionName to whatever is defined in the AndroidManifest file for the specific flavor I'm building.
So if I'm only building one of the 4 defined flavors I have, like:
gradle assembleFlavor1Debug
I was expecting Flavor1 to have the same version name as the one defined for its specific manifest (because of the merging of manifest files), but that's not happening.
How can I know, during build time, which specific flavor is being built?
Because if I know what flavor is being run,
I can extract the respective versionName from the manifest and set it on android.defaultConfig.versionName,
which solves my problem.
As of at least Android Studio 3.1.1 you can do this...
defaultConfig {
versionName "1.0.0"
}
flavorDimensions "dimen1", "dimen2"
productFlavors {
'flavor1' {
dimension "dimen1"
versionNameSuffix "-F1"
}
...
'flavorA' {
dimension "dimen2"
versionNameSuffix "-FA"
}
}
Then for variant flavor1FlavorA the versionName would be 1.0.0-F1-FA
https://developer.android.com/studio/build/build-variants#product-flavors
You can do this in this way
productFlavors
{
test
{
applicationId 'com.example.test'
versionName '1.0.0.test'
versionCode 1
}
product
{
applicationId 'com.example.product'
versionName '1.0.0.product'
versionCode 1
}
}
Is it possible to change the package name of an Android application using Gradle?
I need to compile two copies of the same app, having a unique package name (so I can publish to the market twice).
As a simpler alternative to using product flavours as in Ethan's answer, you can also customise build types.
How to choose between the approaches:
If you need different package names to be able to have both debug and release apks installed on a device, then use the build type approach below, as Gradle plugin docs agree. In this case flavours are an overkill. (I think all projects should by default do this, as it will make life easier especially after you've published to the store and are developing new features.)
There are valid uses for product flavours, the typical example being an app with free and paid versions. In such case, check Ethan's answer and read the documentation too: Configuring Gradle Builds and Gradle Plugin User Guide.
(You can also combine the two approaches, which results in every build variant having distinct package name.)
Build type configuration
For debug build type, and all other non-release types, define applicationIdSuffix which will be added to the default package name.
(Prior to Android Gradle plugin version 0.11 this setting was known as packageNameSuffix.)
android {
buildTypes {
debug {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
}
beta {
applicationIdSuffix '.beta'
versionNameSuffix '-BETA'
// NB: If you want to use the default debug key for a (non-debug)
// build type, you need to specify it:
signingConfig signingConfigs.debug
}
release {
// signingConfig signingConfigs.release
// runProguard true
// ...
}
}
}
Above, debug and release are default build types whose some aspects are configured, while beta is a completely custom build type. To build the different types, use assembleDebug, assembleBeta, etc, as usual.
Similarly, you can use versionNameSuffix to override the default version name from AndroidManifest (which I find very useful!). E.g. "0.8" → "0.8-BETA", as configured above.
Resources:
This example is straight from Xavier Ducrohet's "Google I/O 2013: The New Android SDK Build System" presentation.
Build Types in the User Guide.
Myself I've been using productFlavors so far for this exact purpose, but it seems build type customisation may be closer to my needs, plus it keeps the build config simpler.
Update (2016): I've since used this approach in all my projects, and I think it definitely is the way to go. I also got it included in Android Best Practices guide by Futurice.
You could so something like this
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor1", "flavor2"
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
You can also change the field android.defaultConfig.applicationId if you want to do one-off builds.
Taken from: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration
With the gradle plugin version of 1.0.0+ you have to use applicationId as stated in the migration guide
Renamed Properties in ProductFlavors
packageName => applicationId
Thus in your build.gradle you would now use:
productFlavors {
flavor1 {
applicationId "com.example.flavor1"
}
flavor2 {
applicationId "com.example.flavor2"
}
}
From Ethan's answer, both flavorGroups and packageName both are not available anymore. Below works as of March 2015.
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
flavorDimensions "flavor"
productFlavors {
flavor1 {
flavorDimension "flavor"
applicationId "com.example.flavor1"
versionCode 20
}
flavor2 {
flavorDimension "flavor"
applicationId "com.example.flavor2"
minSdkVersion 14
}
}
}
I did not want to use Flavors, so I found a way to do so with buildTypes. I did this by changing my app/build.gradle file as follows:
defaultConfig {
applicationId "com" // See buildTypes.type.applicationIdSuffix
...
}
...
buildTypes {
debug {
applicationIdSuffix ".domain.name.debug"
...
}
releaseStaging {
applicationIdSuffix ".compagny.staging"
...
}
release {
applicationIdSuffix ".domain.name"
...
}
}
This allows me to have 3 apps next to each other on my devices.
I hope this helps others.