I am completely new to Product Flavors and I have gone through many links to understand it. But there are few doubts which are still not clear. I am having 3 product flavors i.e: qa, dev and prod. I have only created these three product flavors because I need to change the URLs and some API keys for different flavors which I have done by creating 3 different packages and placing the same java(having the URLs) file in the app/src directory. This is how my build.gradle. What are the mandatory things I need to add in each flavor? Something related to: proguard, signingConfigs:
android {
useLibrary 'org.apache.http.legacy'
compileSdkVersion 26
buildToolsVersion '26.0.2'
flavorDimensions "default"
defaultConfig {
applicationId "com.sagar.demo"
minSdkVersion 21
targetSdkVersion 25
multiDexEnabled true
versionCode 67
versionName "1.0.0" //Update Version build number
vectorDrawables.useSupportLibrary = true
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
externalNativeBuild {
cmake {
cppFlags ""
}
}
}
signingConfigs {
release {
storeFile file("myKeystore")
storePassword "Keystore2017"
keyAlias "SagarSuri"
keyPassword "Keystore2020"
}
}
buildTypes {
debug {
debuggable true
minifyEnabled false // shrink
useProguard false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
release {
debuggable false
minifyEnabled true
useProguard true
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
productFlavors {
qa {
dimension "default"
}
prod {
dimension "default"
signingConfig signingConfigs.release
}
dev {
dimension "default"
}
}
}
The way product flavors work is such that you'll end up with the number flavors in each dimension multiplied by the number of buildTypes, in your case you have 3 flavors in a single dimension and 2 build types which ends up with 3x2=6 build variants which are the following:
qaDebug
qaRelease
prodDebug
prodRelease
devDebug
devRelease
Each combination is an actual combination of the related product flavor config and the related build type config combined. Meaning for variant qaDebug, it's configuration are from the defined under qa and from the defined under debug combined. Hence if debug already defines the proguardFiles there's generally no need to define it in qa, unless if qa requires extra proguard configs for it's own code then that's a different matter that needs to be decided and hence proguard should be defined specific for each flavor and not in the build types.
Another aspect I'd like to point out is signingConfig which here is defined the same value for prod and release. This means that any combination that starts with prod or ends with Release will have the signingConfig set, which in this case are: qaRelease, prodDebug, prodRelease and devRelease.
Hence the configuration is really up to your choice and design, and not all projects will have the same config.
Related
My Android project has multiple build type and productFlavors
flavorDimensions "default"
productFlavors {
favor1 {
applicationId "com.abc.android"
versionCode 1
versionName "1"
}
flavor2 {
applicationId "com.abc.android"
versionCode 1
versionName "2"
}
}
buildTypes {
staging {
debuggable true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debug
}
develop {
applicationIdSuffix ".develop"
debuggable true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debug
}
I have placed my file, say(Abc.java) under each of flavor1staging, flavor1develop, flavor2staging, flavor2develop directory
I can do ./gradlew assemblefalor1staging on my local Android studio and it works fine but when run using travis it cannot map the file and gives me error Unresolved reference Abd
Similarly for any string resources that are defined in the flavorbuild folders but not in the main folder
I have a question does the build is working fine if you give it only 1 build type?
Because according to Travis-CI they do not mention about supporting multiple build types in this link
https://docs.travis-ci.com/user/languages/android/
As all builds in the example containing only one build as you can see in these examples
https://github.com/andrewhr/rxjava-android-example/blob/master/app/build.gradle
https://github.com/pestrada/android-tdd-playground/blob/master/app/build.gradle
Please follow these projects if the project working fine after you make build.gradle as it is shown in example then add multiple builds if then gives issues need to check also log.trace of android & maybe not supported.
make it simple then complex the solution so that you could find where is the error.
I only want to change application id in gradle file, but dont want to change package name.
Is it possible?
It is not recommended to change your application id. What you can do is change your application suffix.
As an example, if your application id is com.example.my_app then add different suffixes for different build types, such as com.example.myapp.dev for debug.
Go to app/build.gradle file and on android block add the suffix you want:
buildTypes {
release {
applicationIdSuffix ".production"
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
applicationIdSuffix ".dev"
versionNameSuffix '-DEBUG'
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
Read more about it here
No problem. You can change your application Id as long as your app is not on store. If you change your application id, It would immediately become a different app for google play.
I have many apps with different package name and application ids.
Yes you can change androidId in defaultConfig.
android {
compileSdkVersion 27
buildToolsVersion '27.0.3'
defaultConfig {
applicationId "com.somepkg" // <- we can change applicationId in defaultConfig
minSdkVersion 21
targetSdkVersion 26
vectorDrawables.useSupportLibrary = true
....
}
}
Also we can change applicationId in flavors use suffix or override it:
flavorDimensions "app"
productFlavors {
qa {
dimension "app"
applicationIdSuffix = ".qa" // <- add suffix (it will be )
}
production {
applicationId = "com.someotherpkg" // <- we can change applicationId in flavors
dimension "app"
}
}
However your src files will be still in the same folders.
I tried to test the release build of the app. So I have added the below config to build.gradle of my app. But that didn't make any effect. Test always runs on debug build
android {
compileSdkVersion 24
buildToolsVersion "24.0.0"
defaultConfig {
applicationId "com.****.****"
minSdkVersion 15
targetSdkVersion 22
versionCode 1
versionName "1.0 Beta"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
testBuildType "release"
signingConfigs {
release {
keyAlias '******'
keyPassword '*****'
storeFile file('path to keystore')
storePassword '*****'
}
}
buildTypes {
release {
minifyEnabled true
debuggable true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
debug {
multiDexEnabled true
}
}
}
When searched for answers in other SO thread I found testBuildType "release" will run test on release build but it did not work
I'm not sure I got it all, but a few things :
You can test your release with the build variant menu on Android studio (menu at the bottom left) (#Sagar Chavada suggestion)
When you generate your signed apk with Android studio you can choose at the end the build type, release in your case
I know it's for testing purpose but debuggable true in your realease build won't allow you to push it on Google play
Whenever you are building a project and want to create a signed apk then
Add following code in to android {} in your build.gradle file.
productFlavors {
RELEASE {
applicationIdSuffix ".release"
versionNameSuffix "-release"
}
DEBUG {
applicationIdSuffix ".debug"
versionNameSuffix "-debug"
}
}
Go to Android SDK --> Build.
Tap on Generate Signed APK
It will ask to create a debug or Signed build (apk format)
Then select release flavour and generate apk.
i have this build config in my gradle file ?
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
}
debug {
applicationIdSuffix ".debug"
versionNameSuffix ".debug"
}
qa {
applicationIdSuffix ".qa"
versionNameSuffix ".qa"
}
}
sourceSets { debug { res.srcDirs = ['src/debug/res', 'src/debug/res/values'] } }
}
why when i am try to run qa it trow me and error for not having key for this flavor ?
The only build type for which Gradle can build your project "out of the box" is debug, as the Android Plugin for Gradle knows to use the plugin-created debug signing keystore. For everything else, you either need to:
Configure a separate signing keystore (e.g., for release)
Initialize the new build type from the debug build type, akin to using a copy constructor, so it uses the same rules that debug does for signing
In the following sample, I want to define a new mezzanine build type, giving it the same signing configuration as I use for release. So, I use mezzanine.initWith(buildTypes.release) to set up mezzanine as a copy of release, then continue to configure it with different rules:
apply plugin: 'com.android.application'
android {
compileSdkVersion 19
buildToolsVersion "21.1.2"
defaultConfig {
versionCode 2
versionName "1.1"
minSdkVersion 14
targetSdkVersion 18
}
signingConfigs {
release {
storeFile file('HelloConfig.keystore')
keyAlias 'HelloConfig'
storePassword 'laser.yams.heady.testy'
keyPassword 'fw.stabs.steady.wool'
}
}
buildTypes {
debug {
applicationIdSuffix ".d"
versionNameSuffix "-debug"
}
release {
signingConfig signingConfigs.release
}
mezzanine.initWith(buildTypes.release)
mezzanine {
applicationIdSuffix ".mezz"
debuggable true
}
}
}
In your case, you would use something like qa.initWith(buildTypes.debug) before configuring the rest of the qa build type.
I've been trying to build different product flavours to allow multiple side-by-side installs for our QA teams so I changed the applicationId to be different in each one.
buildTypes {
debug {
applicationId = "com.mypackagename.qa"
....
}
release {
applicationId = "com.mypackagename"
....
}
development {
applicationId = "com.mypackagename.development
....
}
}
However when I attempt to install them all, the release version is installed alone but both the development and the debug end up replacing each other.
Any thoughts on how to get them to install side by side?
Try to add versionNameSuffix. This is how it should look like:
buildTypes {
debug {
versionNameSuffix ".dev"
applicationIdSuffix '.dev'
}
iqa {
versionNameSuffix ".IQA"
debuggable true
signingConfig signingConfigs.debug
applicationIdSuffix '.IQA'
}
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}