Today I noticed that my debug build broke because the BuildConfig.VERSION_NAME now returns
1.6-debug
instead of
1.6
which is how it used to work before. Does anyone know if there's any documentation changes around this change?
If you're building the debug variant, it now appends -debug when you call BuildConfig.VERSION_NAME which is not the case before.
Regardless of whether it's a release or debug build, the value of BuildConfig.VERSION_NAME is always the same.
defaultConfig {
applicationId "com.myapplication.id"
minSdkVersion 21
targetSdkVersion 29
versionCode 106
versionName "1.6"
multiDexEnabled true //important
vectorDrawables.useSupportLibrary = true
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
debug {
minifyEnabled false
useProguard false
debuggable true
buildConfigField "Boolean", "DEBUG_MODE", "true"
versionNameSuffix "-debug"
}
}
Remove versionNameSuffix "-debug" in your build.gradle file:
buildTypes {
debug {
....
//versionNameSuffix "-debug"
}
}
You can check the doc:
Version name suffix. It is appended to the "base" version name when calculating the final version name for a variant.
In case there are product flavor dimensions specified, the final version name suffix will contain the suffix from the default product flavor, followed by the suffix from product flavor of the first dimension, second dimension and so on.
VERSION_NAME is versionName in your build.gradle. Maybe you have multiple build files for different build variants or just append the build variant to your versionName.
Related
I want to add the version code as a suffix of versionNameSuffix.
Currently, I have:
debug {
versionNameSuffix ".debug"
}
How can I have something like:
debug {
versionNameSuffix ".debug.versionCode"
}
My version code is based on the productFlavors:
productFlavors {
free {
versionCode 123
}
}
#Resolution: I move versionCode out from productFlavors to root level and use the accepted anwser to inject versionCode in versionNameSuffix
Create constant version code in your app build.gradle
def versionCode = 1
Then in your flavours
debug {
versionNameSuffix ".debug.${versionCode}”
}
Use the same version code in your defaultconfig also
defaultConfig {
versionCode ${versionCode}
}
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.
This is a question about package names in android. I currently have two build flavors in gradle. Production and Staging.
I have created a google play store account and i want users to alpha and beta test my app. The staging app currenly has a package name of:
com.mobile.myapp.staging while the production flavor has a package name of com.mobile.myapp.
so we have
com.mobile.myapp.staging vs com.mobile.myapp
in the end i clearly want to promote com.mobile.myapp to production not the staging. but i'd like the users to test with the staging variant for a long while (as its connected to staging apis . etc etc.)
How can i do this ? would i have to create two different apps in the google play store ? I am wondering if i have to do this as
they both have different package names. They both will be signed with the same keystore. Please help.
my gradle file looks like this:
apply plugin: 'com.android.application'
android {
compileSdkVersion 25
buildToolsVersion "25.0.3"
defaultConfig {
minSdkVersion project.ext.minimumSdkVersion
//check top level build.gradle file for attributes -
targetSdkVersion 25
applicationId "com.mobile.myapp"
versionCode 150010203
versionName 1.2.3
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
//renderscriptTargetApi 25
//renderscriptSupportModeEnabled true
multiDexEnabled true
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
dexOptions {
javaMaxHeapSize "6g"
}//for out of memory gc overhead error
lintOptions {
abortOnError false
}
productFlavors {
def STRING = "String"
def BOOLEAN = "boolean"
def TRUE = "true"
def FALSE = "false"
def FLAVOR = "FLAVOR"
def RETROFIT_LOG_ALL = "RETROFIT_LOG_ALL"
def BASE_ENDPOINT = "BASE_ENDPOINT"
staging {
// applicationId "com.mobile.myapp.staging"
buildConfigField STRING, BASE_ENDPOINT, '"https://api.flyingSaucerxx-staging.com"'
buildConfigField BOOLEAN, RETROFIT_LOG_ALL, TRUE
manifestPlaceholders = [appDrawerName: "FlyingSaucer-Staging"]
applicationIdSuffix '.staging'
versionNameSuffix '-STAGING'
}
prod {
buildConfigField STRING, BASE_ENDPOINT, '"https://api.flyingSaucerxx.com"'
buildConfigField BOOLEAN, RETROFIT_LOG_ALL, FALSE
manifestPlaceholders = [appDrawerName: "FlyingSaucer"]
}
}
}
///.. dependencies below
It is not possible to use different package names in Google Play Store for the same app.
So the only option you have is to change package name of your staging app to production one. And submit it to alpha/beta testers. And sure watch out to not promote it to production.
Another option is to use other delivery channels like hockeyapp or crashlitics beta.
Yesterday, I updated my google services gradle plugin to this:
dependencies {
classpath 'com.android.tools.build:gradle:2.2.0'
classpath 'com.google.gms:google-services:3.0.0'
}
After that, I am getting below error in my devDebug flavour build:
Error:org.gradle.api.GradleException: No matching client found for package name 'com.example.android.dev'
Here are the relevant part of my app level build.gradle file:
defaultConfig {
applicationId 'com.example.android'
multiDexEnabled true
minSdkVersion 16
targetSdkVersion 24
versionCode 47
versionName "1.3.2"
signingConfig signingConfigs.myConfig
renderscriptTargetApi 24
renderscriptSupportModeEnabled true
}
buildTypes {
debug {
applicationIdSuffix = ".dev"
resValue "string", "app_name", "example-debug"
}
release {
minifyEnabled false
shrinkResources false
resValue "string", "app_name", "example"
signingConfig signingConfigs.myConfig
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
productFlavors {
dev {
// dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
// to pre-dex each module and produce an APK that can be tested on
// Android Lollipop without time consuming dex merging processes.
minSdkVersion 21
}
prod {
// The actual minSdkVersion for the application.
minSdkVersion 16
}
}
This error does not come in my prodRelease product flavour build. How can I resolve it?
In your debug build type you are using this package:
debug {
applicationIdSuffix = ".dev"
}
This message
No matching client found for package name 'com.example.android.dev'
means that your google-services.json doesn't contain this package.
Follow these steps:
Go to Firebase console
add another android app registering also this package
Export again the google-services.json
Re-register your key on console.developers
Finally fixed the issue.
The trick is to add another app to the Firebase console with the debug package name and debug SHA1 fingerprint.
Doing this essentially creates 2 apps but the google-services.json file downloaded from any app contains information about both apps.
I need to set two different android build types i.e. staging and release.
defaultConfig {
applicationId "com.app.testing"
minSdkVersion 19
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
buildConfigField "String", "SERVER_URL", '"http://testing.com"'
}
dev {
applicationIdSuffix ".dev"
buildConfigField "String", "SERVER_URL", '"http://testing.com"'
}
Now I want to add versionName for each build type. How can I do that?
Edit
productFlavors{
release {
versionname = "1.0"
}
dev{
versionname = "1.0"
}
}
You can also use different version names for each build type without using flavors
In your app-module build.gradle:
defaultConfig {
...
versionName ""
}
...
buildTypes {
debug {
...
versionNameSuffix 'debug-version-1'
...
}
release {
...
versionNameSuffix 'version 1'
...
}
}
versionName "" did the trick.
You can use productFlavors like below:
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
}
}
You can define it under your default config. You can change from build variants. You can combine your build types with flavors.
Good luck.
The version code could be in minor versions to such as the following:
defaultConfig {
applicationId "com.app.testing"
minSdkVersion 19
targetSdkVersion 23
versionCode 3.2.1
versionName "1.0"
}
In the example above 3 denotes a major release which drastically updates the way an app would look like or its functionality. 2 denotes a bug fix/improvement which updates the app in some way or another, while 1 denotes a minor update or fix.
Hope this helps.
I need to set two different android build types i.e. staging and
release.
Defining buildTypes
As in your question above, you have correctly defined your two buildTypes, "release" and "dev".
Now I want to add versionName for each build type. How can I do that?
Iterating through buildTypes
A clean and more programmatic way to define your versionName (or any other defaultConfig parameter for that matter) for different buildTypes, is to iterate through all application variants and perform a specific action for your buildTypes using if statements:
android {
...
defaultConfig {
...
applicationVariants.all { variant ->
if(variant.buildType.name == "release") {
//Release
versionName "1.2.3"
} else if(variant.buildType.name == "dev") {
//Dev
versionName "3.2.1"
}
}
}
}