I'm writing my first android app, and I'm just getting started with product flavors. I have an ad-supported app in beta, and I'm writing a paid version with no ads. I can compile both flavors, I think. When I open the gradle window, I see targets like "compile AdsDebugSources" and "compile PremiumDebugSources."
Now, if I double-click on either of those, the build runs to completion without error, but I can't figure out how to run the results. If I click on the green "Run" arrow at the top of the screen, I can never run the premium app.
There's only one entry, "app" that results in a an apk being installed and run on the attached device, and it's the AdsDebug version. I guess I need to add a new configuration, but I can't find any documentation that even mentions the word "flavor."
I've tried adding a configuration, but I don't understand what the questions mean. I looked at the settings for the default app, but they don't seem to mean much. How do I tell it that I want the premium version of my app?
Or does my problem have nothing to do with configurations? I've noticed that when I look at the Build/Edit Flavors the two flavors are listed, but none of the data fields are filled in. I would have thought that these would be copied from the manifest. Have I neglected something?
All I did to set up the flavors was to add this code to the app level build.gradle file:
flavorDimensions "dummy"
productFlavors {
ads {
dimension "dummy"
applicationId 'com.example.myApp.ads'
}
premium {
dimension "dummy"
applicationId 'com.example.myApp.premium'
}
}
What else do I need to do?
Open the Build Variants tool in Android Studio. By default, this is docked on the left.
It will show a list of modules in your project, with a drop-down for each indicating the build variant that will be used by the Run button.
SOLUTION
If you want to create different type product flavours (like different urls: development url, Quality url and production url of our application)
so you want to follow this code is working properly.
android {
compileSdkVersion 30
buildToolsVersion "30.0.2"
defaultConfig {
applicationId "com.premsinghdaksha"
minSdkVersion 17
targetSdkVersion 30
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
flavorDimensions "client"
productFlavors {
// use for production debug and release build
production {
dimension "client"
buildConfigField("String", "BASE_URL", "YourURL")
//if you want to use string anywhere of app show you define
// buildConfigField and get value where you want to use.
buildConfigField("String", "Shop_", "\"Shop1\"")
// production app name
//if you want change application name and app icon so you define
// resValue, manifestPlaceholders and get these value in Manifests file.
resValue "string", "app_name", "Your production name"
//production app icon
manifestPlaceholders = [
appIcon : "#mipmap/app_icon",
appIconRound: "#mipmap/app_icon_round"
]
signingConfig signingConfigs.release
}
// use for quality debug and release build
quality {
dimension "client"
buildConfigField("String", "BASE_URL", "YourQualityurl")
buildConfigField("String", "Shop_", "\"Shop2\"")
//use for quality app name
resValue "string", "app_name", "quality App name"
// use for quality app icon
manifestPlaceholders = [
appIcon : "#mipmap/quality_app_icon",
appIconRound: "#mipmap/quality_app_icon_round",
]
}
// use for development debug and release build
development {
dimension "client"
buildConfigField("String", "BASE_URL", "development url")
buildConfigField("String", "Shop_", "\"Shop3\"")
//use for dev app name
resValue "string", "app_name", "developer app name"
//use for dev app icon
manifestPlaceholders = [
appIcon : "#mipmap/developer_icon",
appIconRound: "#mipmap/developer_icon_round"
]
}
}
}
If you want to create signingApp for live application, So you have follow this code in build.gradle(:app) in android{}.
signingConfigs {
// use for signed apk
release {
storeFile file("../premsingh.jks")
storePassword "app#app"
keyAlias "key0"
keyPassword "app#app"
v1SigningEnabled true
v2SigningEnabled true
}
}
Result will be showing on build Variants and click drop down Button use click of variants.
Related
I am working on making a large project modular. I have separated the code and layout files and everything is working fine except one issue.
I needed to create 3 build types in the module namely, beta, stage and live (for a reason mentioned later). Now there is one thing I couldn't understand.
When running from Android Studio directly I can select which build variant of the library module to use while building. but
When generating a signed apk, it doesn't ask for the build type of the library.
There must be some
defaults which could be set in order to configure this. I am looking for those config options which can be used
and
Which build type of the library is by default selected when generating signed apk ?
The reason I created build variants within the library module is that I am using Content Provider in the module and I was CONTENT_PROVIDER_AUTHORITY_CONFLICT error on installing multiple build types simultaneously in the same device.
So in order to install beta, stage and live builds simultaneously I added the Content Authority as a string resource in the build.gradle
apply plugin: 'com.android.library'
android {
compileSdkVersion Integer.parseInt(project.COMPILE_SDK_VERSION)
buildToolsVersion project.BUILD_TOOLS_VERSION
defaultConfig {
minSdkVersion Integer.parseInt(project.MIN_SDK_VERSION)
targetSdkVersion Integer.parseInt(project.TARGET_SDK_VERSION)
vectorDrawables.useSupportLibrary true
}
buildTypes {
beta {
minifyEnabled false
resValue("string", "account_type", "com.****.****.dev")
resValue("string", "_authority", "com.****.****.dev.syncadapter.finance")
buildConfigField "String", "FinanceContentProvider", "\"com.****.****.dev.syncadapter.finance\""
}
staging {
minifyEnabled false
resValue("string", "account_type", "com.****.****.stage")
resValue("string", "_authority", "com.****.****.stage.syncadapter.finance")
buildConfigField "String", "FinanceContentProvider", "\"com.****.****.stage.syncadapter.finance\""
}
live {
minifyEnabled false
resValue("string", "account_type", "com.****.****.live")
resValue("string", "_authority", "com.****.****.live.syncadapter.finance")
buildConfigField "String", "FinanceContentProvider", "\"com.****.****.syncadapter.finance\""
You need to use this below build types:
flavorDimensions 'tier'
productFlavors {
beta {
buildConfigField("Your_field", "Data", "Data")
}
staging {
buildConfigField("Your_field", "Data", "Data")
}
live {
buildConfigField("Your_field", "Data", "Data")
}
android.applicationVariants.all { variant ->
variant.outputs.all {
outputFileName = "AppName_${variant.productFlavors[0].name}-${buildType.name}-${defaultConfig.versionCode}.apk"
}
}
}
Hope this helps.
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 am working for a company which has this "foo" app on the store, the app is a helper for our hardware which is revelled by resellers. We made sure that the name is as generic as possible - in order for our vendors to be able to market the app as "their app".
However - some re-sellers do want to have their exact name and icon on the app. And they are willing to pay so, I need to make this happen.
Questions:
I understand that I am looking for build variants. But still, how can I modify the apk-package-name , display name is default launcher icon using build variants?
Is this permitted...? I am not "officially" spamming the store, but it feels like I could get banned for doing that exactly.
Code signing - I will upload the APK my self, and I will need to sign using different certificates (whatever it's called on android). Again - this is vague, and I cannot find documentation on this subject.
I also plan on releasing a beta version of my app in this way. I am currently using the standard mechanism, but this means that testers cannot show case the app to customers (as it's not finished or crashing most of the time) [1]
Does the term "white labeling" apply here...?
[1] the joys of working in a small company :)
You can do this with build variants as you suspected but also you would likely need Flavors.
Here is an example gradle file that has multiple build types and flavors. You set the ApplicationId (packagename used in Play Store) in the flavor settings.
Set up the signing in each type/flavor. You can add resources, icons, manifests etc that are specific to each flavor. You can even replace whole class files so customer specific code is only included in the apk for the customer you are building for.
defaultConfig {
applicationId "uk.co.foo.default"
minSdkVersion 14
targetSdkVersion 23
versionCode = 113
versionName = "3.2.3"
}
signingConfigs {
release {
storeFile file("X:\\Android Projects\\Keystore\\MyKeys.jks")
storePassword "MyPassword"
keyAlias "KeyAlias"
keyPassword "itsasecret"
}
}
productFlavors {
Customer1 {
applicationId "uk.co.foo.customer1"
}
Customer2 {
applicationId "uk.co.foo.customer2"
}
}
buildTypes {
debug {
applicationIdSuffix ".debug"
versionNameSuffix " Debug"
}
beta {
applicationIdSuffix ".beta"
versionNameSuffix " Beta"
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
signed {
minifyEnabled false
debuggable true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
Here is the folder structure for adding resources for each type\flavor. In this example, the second flavor is called "fan". The "main" folder is used by default. Each type and flavors resources are merged into the apk (replacing any of the same name in the main folder) depending on which build you choose in the "Build Variants" section of Android Studio.
Android Studio will display which folders are in effect for the current build as shown highlighted in this image.
Edit - full official documentation is available here: https://developer.android.com/tools/building/configuring-gradle.html
Hi I'm trying to implement android app flavor (free and full) to live wallpaper. In eclipse, I used to use this following code to open live wallpaper preview from my own android Activity:
Intent intent = new Intent();
intent.setAction(WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER);
String pkg = WallpaperService.class.getPackage()
.getName();
String cls = WallpaperService.class.getCanonicalName();
intent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
new ComponentName(pkg, cls));
But now it does not work correctly as the free and full flavor are using same package name with just different applicationId in android studio. The problem is when it starts either in free or full version, it will goto full version no matter how, regardless of what flavor it is. I specify app flavor using applicationId in project gradle like this:
productFlavors {
free {
applicationId "com.kkl.app.free"
}
full {
applicationId "com.kkl.app"
}
}
How do we make it to get the correct package name that matches the app flavor?
You can call getPackageName() in your Activity to get Android packageName. This will be packageName from manifest file i.e. the one equal to current applicationId.
Method documentation can be found here.
Fixed by using the following:
intent.setAction(WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER);
String pkg = getPackageName();
String cls = WallpaperService.class.getCanonicalName();
intent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
new ComponentName(pkg, cls));
Special thank to Lingviston
You can do a lot with flavors, but what you are trying to do is far simpler than anyone has answered.
First you have a build variant to select your flavor for debugging and running. So use this, otherwise all your debugging will use default main release.
Secondly, you don't have to get package name, just use a build config flag or check flavor. I.E.
android {
signingConfigs {
releaseA35Demo {
storeFile file("$projectDir/../yaskeystore.jks")
storePassword System.getenv('YOUR_APP_STUDIO_STORE_PASSWORD')
keyAlias System.getenv('YOUR_APP_STUDIO_KEY_ALIAS')
keyPassword System.getenv('YOUR_APP_STUDIO_KEY_PASSWORD')
}
}
flavorDimensions 'default'
productFlavors {
a35Demo {
dimension 'default'
applicationId "com.appstudio35.yourappstudio"
buildConfigField "String", "SERVER_URL", '"http://fakeNumbers.compute-1.amazonaws.com:3006"'
buildConfigField "int", "BUSINESS_ID", "1"
versionCode 1
versionName "0.01.01-b1"
minSdkVersion 21
}
a35DemoDev {
dimension 'default'
applicationId "com.appstudio35.yourappstudio.dev"
buildConfigField "String", "SERVER_URL", '"http://fakeNumbers2.compute-1.amazonaws.com:3006"'
buildConfigField "int", "BUSINESS_ID", "2"
versionCode 1
versionName "0.01.01-b1"
minSdkVersion 21
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
productFlavors.a35Demo.signingConfig signingConfigs.releaseA35Demo
productFlavors.a35DemoDev.signingConfig signingConfigs.releaseA35Demo
}
}
}
Then simply reference it in code like:
BuildConfig.BUSINESS_ID
Wherever you need it. Just make sure you don't accidentally use the BuildConfig of a library project when it auto imports the BuildConfig.
Next way is if you want to check your flavor you can simply do
BuildConfig.FLAVOR to see which one you are on. However, keep in mind there are some compiler warnings about using it because you are checking against a flavor and the BuildConfig assumes it will ALWAYS be whatever you are currently in for the Build Variant dropdown, Which is not true, you can ignore this always true or always false warning, I assure you it works.
Lastly your package issue is just because you are debugging the wrong build variant. I'll add an image so you can see where to change that.
Hope that helps.