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.
Related
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.
I have used build.gradle(app) to create different flavors of apk.
But installing different flavors of same apk overrides the previous one.
I want to create different apks to run on same device simultaneously.
I want to create different apk with different appicon which can be installed on same device and run simultaneously.
Any link or tutorial or direct help is appreciated.
Thanks in advance.
Change the PackageName of the flavor
Sample Gradle File
apply plugin: 'com.android.application'
android {
lintOptions {
abortOnError false
}
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
minSdkVersion 14
targetSdkVersion 16
}
buildTypes {
debug {
minifyEnabled false
zipAlignEnabled true
}
release {
minifyEnabled true
zipAlignEnabled true
}
}
productFlavors {
Flavor1 {
applicationId "com.falvor.one" //This is where you change the package name
}
Flavor2 {
applicationId "com.falvor.two"
}
}
}
Flavor Hierarchy in Android
- src/main/java
- src/flavor1
--------------Java
----------------Your java files
--------------res
----------------Drawable
src/flavor2/java
For more understanding, follow this link
You need to create new productFlavors in your gradle file, like this;
productFlavors {
Flavor1 {
applicationId 'com.project.fl1'
signingConfig signingConfigs.xx
versionCode 1
}
Flavor2 {
applicationId 'com.project.fl2'
signingConfig signingConfigs.xx
versionCode 1
}
Flavor3 {
applicationId 'com.project.fl3'
signingConfig signingConfigs.xx
versionCode 1
}
}
The important thing here is to give each one a unique applicationId, they can then be installed on the same phone.
This post explains exactly how to achieve what you want step by step.
Most importantly:
add the product flavours container to the app build.gradle file
productFlavors {
free {
applicationId "antoniocappiello.com.buildvariantsexample.free"
}
paid {
applicationId "antoniocappiello.com.buildvariantsexample.paid"
}
}
create inside src a directory with the exact name of the product flavour that you want to look different from the main variant, for example with the configuration at step 1 the directory name could be paid or free . And inside that directory create the subfolder res/drawable where you are going to place your new app launcher icon.
Directory structure example
I added google plus login in my android app.
I want to create apk three different applicationId with productFlavors in gradle.
When i create apk diffrent applicationId, google plus login does not work.
I tried new client id in developer console with new applicationId, but console wants packagename in AndroidManifest.xml
How can i login google plus with different applicationId in my app.
Thanks,
//gradle
compileSdkVersion 22
buildToolsVersion "21.1.2"
defaultConfig {
minSdkVersion 18
targetSdkVersion 21
}
productFlavors {
development {
applicationId "com.msevgi.myapp.development"
versionCode 46
versionName "1"
flavorDimension "type"
}
beta {
applicationId "com.msevgi.myapp"
versionCode 46
versionName "1"
flavorDimension "type"
}
internal {
applicationId "com.msevgi.myapp.internal"
versionCode 46
versionName "1"
flavorDimension "type"
}
}
buildTypes {
release {
zipAlignEnabled true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-android-optimize.txt'
debuggable false
}
debug {
zipAlignEnabled true
debuggable true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-android-optimize.txt'
}
}
//AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.msevgi.myapp">
According to this:
"that matches a package name and SHA1 signing-certificate fingerprint"
I think you should:
Specify a package name ("applicationId" in build.gradle) for per flavor/type (as you have done).
Get the "SHA1 signing-certificate fingerprint" by running the "keytool" for each "keystore" you use to sign the APK. This means the default "~/.android/debug.keystore" for your DEBUG build, or the "keystore" which is not in the "build.gradle" but specified by you when run "Generate Signed APK" in Android Studio or Eclipse.
Create a credential on the Google API console for each combination of #1 and #2.
I think you should generate an api key for each of your flavor. The package name will be the applicationId of the flavor in your gradle build file.
I'm adding a wearable component to an existing app which uses product flavors in the gradle build to build multiple versions of the app.
I know the package names / application Id's need to match between the mobile and wearable builds, but do I just need to copy the
productFlavors
signingConfigs
buildTypes
from my main mobile app. I'm not quite sure if all of this is needed to get things working or not.
The productFlavors no, unless you are going to do something specific for the wear app with a particular flavor.
The signingConfigs and buildTypes you should copy, the wear app definitely needs to be signed as well. You may adapt the buildType for wear such is enable/disable minify it you want from the main app.
Here's a portion of my own mobile and wear build configs
Mobile
android {
compileSdkVersion 20
buildToolsVersion "20.0.0"
defaultConfig {
applicationId "org.codechimp.qrwear"
minSdkVersion 18
targetSdkVersion 20
versionCode 26
versionName "1.20"
}
productFlavors {
prod {
}
dev {
versionName = android.defaultConfig.versionName + " dev"
}
}
signingConfigs { release }
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
}
Wear
android {
compileSdkVersion 20
buildToolsVersion "20.0.0"
defaultConfig {
applicationId "org.codechimp.qrwear"
minSdkVersion 20
targetSdkVersion 20
versionCode 26
versionName "1.20"
}
signingConfigs { release }
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
}