i want to publish a paid app and free app
i have created flavor of free and paid using this code
productFlavors {
free {
applicationId "com.example.myapp.free"
versionName "1.0-free"
// this boolean can be accessed in java classes by using BuildConfig class
// and now you can identify if your app is the paid version or not
buildConfigField "boolean", "PAID_VERSION", "false"
}
paid {
applicationId "com.example.myapp.paid"
versionName "1.0-paid"
buildConfigField "boolean", "PAID_VERSION", "true"
}
}
I want to know how can upload this app
we need two diffretnt apk for that (paid relese apk and free apk)
or single apk
i need both variant available in playstore
If You have two flavor variant
like
Free with package name as
applicationId "com.example.myapp.free"
Paid with package name as
applicationId "com.example.myapp.paid"
Both are different applicationId so you need to upload in two different apps in play store, Because your applicationId is a playstore app id So it must be a unique
or
You have to remove this line in both flavor and use common applicationId
then
handle like this following way
defaultConfig {
applicationId "com.example.myapp"
}
productFlavors {
free {
versionName "1.0-free"
buildConfigField "boolean", "PAID_VERSION", "false"
buildConfigField "String", "BuildType", "Free"
}
paid {
versionName "1.0-paid"
buildConfigField "boolean", "PAID_VERSION", "true"
buildConfigField "String", "BuildType", "Paid"
}
}
Handle in java code
public void manageFeaturesWithBuildType()
{
String buildType = BuildConfig.BuildType;
if(buildType.equals("Paid"))
{
//Here Enable or Disable your features for paid Build
}
else
{
//Here Enable or Disable your features for free Build
}
}
You got this type of Build variant as shown in image: In your case you can see paidDebug and freeDebug option.
If you want to release paid version then you have to select paidDebug and if you want to release free version then you have to select freeDebug.
Related
I need to create a mobile app artifact for multiple env. The goal is to promote the same artifact across multiple envs (dev, qa, preprod and prod). The mobile artifact uses a saas url which changes from env to env. Please let me know the best practice to do so.
Currently when the artifact passes qa I create another artifact for pre-prod and finally for prod which is time-consuming and prone to mistakes.
I am thinking of creating an active env url and release version api. What is the best practice?
Thanks,
I think android-flavors will solve your problem.
I look like these examples below.
flavorDimensions "default"
productFlavors{
dev{
applicationId "com.amitgupta.trust_app_android.dev"
}
staging{
applicationId "com.amitgupta.trust_app_android.staging"
}
qa{
applicationId "com.amitgupta.trust_app_android.qa"
}
production{
applicationId "com.amitgupta.trust_app_android.production"
}
}
You make also use different URLs based on Different environment.
flavorDimensions "version"
productFlavors {
QA {
buildConfigField "String", "BASE_URL", '"http://qa.com/api/"'
}
production {
buildConfigField "String", "BASE_URL", '"http://production.com/api/"'
}
}
Please, look at these for its implementation.
https://medium.com/#hsmnzaydn/configuration-product-flavors-and-build-variants-in-android-bb9e54d459af
https://www.journaldev.com/21533/android-build-types-product-flavors
For iOS:
You can make use of Schemes and Build configurations in Xcode. Here's the official documentation: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/Articles/BasingBuildConfigurationsonConfigurationFiles.html
I hope this will be of any help.
The following is true if you use gradle:
For top level build.gradle, define appId parameter:
allprojects {
ext {
appId = 'com.my.app'
}
}
For app module's build.gradle, define flavors and use the above parameter:
android {
def globalConfig = rootProject.extensions.getByName("ext")
productFlavors {
dev {
applicationId globalConfiguration["appId"] + ".dev"
...
buildConfigField "String", "YOUR_ENDPOINT", "\"https://my.dev.env/\""
}
qa {
applicationId globalConfiguration["appId"] + ".qa"
...
buildConfigField "String", "YOUR_ENDPOINT", "\"https://my.qa.env/\""
}
}
Build app using specific flavor + use BuildConfig.YOUR_ENDPOINT in code.
To install two different instances of the same app is easy. I just use productFlavors.
The problem comes when I install the app from Google Play and try to install another flavor. I can't have an app from Google Play and a flavor one at the same time but two flavors apps yes.
How can I install both apps in the same phone, Google Play app and Flavor app.
PD: I am using different flavors, this is an example of them:
QA {
resValue "string", "app_name", "My app QA"
applicationId "com.myapp.qa"
}
GOOGLEPLAY{
resValue "string", "app_name", "My app GOOGLE PLAY"
applicationId "com.myapp.release"
}
TESTING {
resValue "string", "app_name", "My app TEST"
applicationId "com.myapp.test"
}
DEVELOPMENT {
resValue "string", "app_name", "My app DEV"
applicationId "com.myapp.dev"
}
Define Flavors
android {
defaultConfig {
applicationId "com.example.myapp"
}
productFlavors {
free {
applicationIdSuffix ".free"
}
pro {
applicationIdSuffix ".pro"
}
}
}
The key is the applicactionIdSuffix
android {
...
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
}
I want to create an application with two flavours one with less features and one with more. How can i do it
Let us suppose there is
A - application
Flavour1 - feature1, feature2
Flavour2 - feature1, feature2, feature3
How to release one apk
and how user will install the application from play store how the user will know which flavour is going to be installed
There is nice documentation from google.
Multiple flavours
You should declare the flavors in the buildfile
android {
...
defaultConfig {...}
buildTypes {...}
productFlavors {
demo {
applicationIdSuffix ".demo"
versionNameSuffix "-demo"
}
full {
applicationIdSuffix ".full"
versionNameSuffix "-full"
}
}
}
After build two apk files will be created. They have different application id so you can publish them as two different applications to the Play Store. For example one free and one paid.
Features
There can be more solutions but the simplest one is to use buildConfigField.
productFlavors {
demo {
applicationIdSuffix ".demo"
versionNameSuffix "-demo"
buildConfigField "boolean", "FEATURE_1", "true"
buildConfigField "boolean", "FEATURE_2", "false"
buildConfigField "boolean", "FEATURE_3", "false"
}
full {
applicationIdSuffix ".full"
versionNameSuffix "-full"
buildConfigField "boolean", "FEATURE_1", "true"
buildConfigField "boolean", "FEATURE_2", "true"
buildConfigField "boolean", "FEATURE_3", "true"
}
}
Then in java source code you can check if features are enabled:
if (BuildConfig.FEATURE_1) {
//run feature
}
Some othe approaches are described in the documentation.
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 used to have the following project flavors:
Apple
Orange
Originally the only difference was the applicationId/packageName. Now there is a single java file that is different. A custom ArrayAdapter to be exact. The solution was to create src/Apple and src/Orange and both inherit from src/main. I removed the java file from src/main and put a copy into src/Apple and src/Orange and modified it appropriately. All was good in the world.
Fast forward a few weeks, now there are about 10 java files that differ between Apple and Orange. Again... no big deal. Easy to handle. Separate java files in src/Apple and src/Orange.
Fast forward to today. I need to modify things up a bit, because I want to have a free and premium version of each. The free and premium versions only differ by a URL. I was going to simply create the new types called:
AppleFree
ApplePremium
OrangeFree
OrangePremium
I have a dilema though. Since now src/Apple and src/Orange have 10 different files that have been changed... if I change any java file in AppleFree I have to make sure I do the same in ApplePremium. I'm kind of at a crossroads and hope my question makes sense at this point. I have come up with three possible solutions, but I'm not sure how I would implement them/what would be the correct approach/the solution is not what I want.
Solution 1:
Use an if statement
if (BuildConfig.FLAVOR==appleFree) {//use free Url} else {// use premium url}
Issue: Both Urls are technically compiled into the apk. I do not want this.
Solution 2:
Have src/AppleFree and src/ApplePremium inherit from an src/Apple parent directory somehow.
Issue: Not sure how I would do this.
Solution 3:
Add the free and premium url right in build.gradle like so?
productFlavors {
appleFree {
applicationId "com.example.apple.free"
versionName "1.0"
url "http://freeurl.com"
versionCode 1
}
applePremium {
applicationId "com.example.apple.premium"
versionName "1.0"
url "http://premiumurl.com"
versionCode 1
}
orangeFree {
applicationId "com.example.orange.free"
versionName "1.0"
versionCode 1
url "http://freeurl.com"
}
orangePremium {
applicationId "com.example.orange.premium"
url "http://premiumurl.com"
versionName "1.0"
versionCode 1
}
}
Issue: Not sure how to make that work.
Any tips are helpful.
EDIT:
Final Solution?
flavorGroups 'fruit', 'paid'
productFlavors {
apple {
flavorGroup 'fruit'
}
orange {
flavorGroup 'fruit'
}
free {
flavorGroup 'paid'
}
premium {
flavorGroup 'paid'
}
appleFree {
applicationId "com.example.apple.free"
versionName "1.0"
buildConfigField 'String', 'BASE_URL', 'http://freeurl.com'
versionCode 1
}
applePremium {
applicationId "com.example.apple.premium"
versionName "1.0"
buildConfigField 'String', 'BASE_URL', 'http://premiumurl.com'
versionCode 1
}
orangeFree {
applicationId "com.example.orange.free"
versionName "1.0"
versionCode 1
buildConfigField 'String', 'BASE_URL', 'http://freeurl.com'
}
orangePremium {
applicationId "com.example.orange.premium"
buildConfigField 'String', 'BASE_URL', 'http://premiumurl.com'
versionName "1.0"
versionCode 1
}
}
There are many possible solutions to your problem. The most native-Gradle solution would be to use Flavor Dimensions, as documented in http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Multi-flavor-variants
This is also similar to what you were thinking about with Solution 2.
It would work something like this:
flavorDimensions 'fruit', 'paid'
productFlavors {
apple {
dimension 'fruit'
}
orange {
dimension 'fruit'
}
free {
dimension 'paid'
}
premium {
dimension 'paid'
}
}
This will give you build variants (and source folders) where it does the combination of all possibilities out of each flavor dimension, maintaining the same order as how the groups are specified in your flavorDimensions statement (i.e. it's appleFree, not freeApple), thus:
* appleFree
* applePremium
* orangeFree
* orangePremium
in your src/ folder, you can have these possibilities:
* src/main
* src/apple
* src/orange
* src/free
* src/premium
* src/appleFree
* src/applePremium
* src/orangeFree
* src/orangePremium
Solution 3
You can use the buildConfigField to specify constants that go in the BuildConfig class on a flavor-by-flavor basis:
productFlavors {
appleFree {
buildConfigField 'String', 'MY_URL', 'value1'
}
applePremium {
buildConfigField 'String', 'MY_URL', 'value2'
}
orangeFree {
buildConfigField 'String', 'MY_URL', 'value3'
}
orangePremium {
buildConfigField 'String', 'MY_URL', 'value4'
}
Solution 1
I was trying to work up something along the lines of Solution 1, but it won't work well for your exact use case. If you have an if condition in Java that tests against a boolean that's declared static final then the compiler can determine statically whether the code is reachable or not, and it will strip it if it's not. Thus:
static final boolean DEBUG = false;
...
if (DEBUG) {
// do something
}
The code in // do something won't get compiled at all. This is an intentional and documented behavior on the part of the Java compiler, and allows you to write expensive debug code that won't get compiled into your release binary. BuildConfig.DEBUG is declared as static final for this exact reason.
There's a BuildConfig.FLAVOR, but it's defined as String, and you don't get the same benefit:
static final String FLAVOR = "orange";
...
if (FLAVOR.equals("apple")) {
// do something
}
The compiler isn't smart enough to do static analysis, see that // do something is unreachable, and not compile it. Note that it will work fine at runtime, but that dead code will be included in your binary.
If it suits you, though, you could steal the buildConfigField approach from above and define an extra boolean variable in some variants that could allow code to be conditionally compiled in. This is more complex than defining the string directly as in Solution 3, but if you find yourself wanting to differentiate behavior without going through the trouble of making flavor-specific subclasses, you could go this route.
Here's how I implemented product flavors inheritance.
stageLt (extends baseLt) - app for Lithuania using stage API
productionLt (extends baseLt) - app for Lithuania using production API
stagePl (extends basePl) - app for Poland using stage API
stagePl (extends basePl) - app for Poland using production API
android {
flavorDimensions "default"
productFlavors {
def API_URL = "API_URL"
def PHONE_NUMBER_PREFIX = "PHONE_NUMBER_PREFIX"
def IBAN_HINT = "IBAN_HINT"
baseLt {
buildConfigField "String", PHONE_NUMBER_PREFIX, '"+370"'
resValue "string", IBAN_HINT, "LT00 0000 0000 0000 0000"
}
basePl {
buildConfigField "String", PHONE_NUMBER_PREFIX, '"+48"'
resValue "string", IBAN_HINT, "PL00 0000 0000 0000 0000 0000 0000"
}
stageLt {
dimension "default"
applicationId "lt.app.stage"
buildConfigField "String", API_URL, '"https://www.limetorrents.pro/"'
}
productionLt {
dimension "default"
applicationId "lt.app"
buildConfigField "String", API_URL, '"https://yts.mx/"'
}
stagePl {
dimension "default"
applicationId "pl.app.stage"
buildConfigField "String", API_URL, '"https://1337x.to/"'
}
productionPl {
dimension "default"
applicationId "pl.app"
buildConfigField "String", API_URL, '"http://programming-motherfucker.com/"'
}
}
// base product flavors will not show up in 'Build Variants' view.
variantFilter { variant ->
if (variant.name.startsWith("base")) {
setIgnore(true)
}
}
}
void setupProductFlavor(baseFlavor, flavor) {
flavor.buildConfigFields.putAll(baseFlavor.buildConfigFields)
flavor.resValues.putAll(baseFlavor.resValues)
flavor.manifestPlaceholders.putAll(baseFlavor.manifestPlaceholders)
// Note that other product flavor properties ('proguardFiles', 'signingConfig', etc.) are not merged.
// E.g. if in base product flavor you declare 'signingConfig', it will not be copied to child product flavor.
// Implement if needed.
}
// Merge 'parent product flavors' with 'child product flavors'
setupProductFlavor(android.productFlavors.baseLt, android.productFlavors.stageLt)
setupProductFlavor(android.productFlavors.baseLt, android.productFlavors.productionLt)
setupProductFlavor(android.productFlavors.basePl, android.productFlavors.stagePl)
setupProductFlavor(android.productFlavors.basePl, android.productFlavors.productionPl)