I have an Android App, which has two flavors: Basic and Advanced.
The Basic is already on the AppStore, with a package name of form com.domain.something. I would like to publish the second as com.domain.something.advanced. Is it possible? Or is the fact that the second is a sub package of the first would cause trouble?
Yes, this is possible and will not cause any problems in the Play Store.
You will want to read the Configure Build Variants guide for more information on setting up a product flavor for your "advanced" version. You can use the applicationIdSuffix in your build types or product flavors to set a suffix on your application ID for that particular variant.
Your build.gradle will end up looking something like this:
android {
defaultConfig {
applicationId "com.domain.something"
}
buildTypes {...}
productFlavors {
basic {...}
advanced {
applicationIdSuffix ".advanced"
}
}
}
You can then either programmatically check your product flavor with the generated BuildConfig class, or put your code for the advanced version in the advanced product flavor's source folder (/src/advanced/java, /src/advanced/res, etc.).
Related
We are trying to provide multiple environments to our end users and want to create one single bundle for both IOS and Android. Currently we have a hidden feature (clicking on the version number to open an environment selection screen: Dev, QA, UAT or Prod). However, I am wondering if there are better or recommended ways of achieving this same effect somehow.
Thanks!
I can help you with Android on managing Environments using Gradle file.
Let's say you have a app with package name - com.company.sampleapp
In gradle your applicationId will be com.company.sampleapp
Now we can create different flavors for different environment and we can also have different applicationId as shown below.
android {
flavorDimensions "default"
productFlavors {
production {
dimension "default"
applicationId 'com.allegion.leopard'
}
//App will have package name appended with .qa
qa {
dimension "default"
applicationId 'com.allegion.leopard.qa'
}
//App will have package name appended with .dev
dev {
dimension "default"
applicationId 'com.allegion.leopard.dev'
}
}
}
Once this is done, you can choose build variants and create APK for that build. Added image for clarity
Hope this helps.
I am setting up Firebase for my Android application and have run into a slight wrinkle/problem. I have multiple product flavors such as the standard dev, qa and prod. These product flavors share the same application id. However, I have one flavor where the application id is different:
productFlavors {
dev {
applicationId "com.acme.myandroidapp"
}
qa {
applicationId "com.acme.myandroidapp"
}
foo {
applicationId "com.acme.foo"
}
prod {
applicationId "com.acme.myandroidapp"
}
This is causing my gradle build to fail with a "No matching client found for package name 'com.acme.foo'" error.
I have looked at both: No matching client found for package name (Google Analytics) - multiple productFlavors & buildTypes and google-services.json for different productFlavors
Unfortunately, neither question deals with the wrinkle of having a different application id for a particular product flavor. I did try putting a copy of the google-services.json file at the base of each flavor but there was no joy.
Thoughts on how do you support different applicationIds with Google Services under Android?
You can Add app for both the application Ids in Project setting in Firebase Console.
By doing so the new google-services.json file will contain two client-info, 1 for each application ID.
Putting a copy of the google-services.json file at at the base of each flavor should solve the issue.
I have a project lets say Project A( Main Project/ Master). I need to create same projects but with same code and different package name Project B and Project C.
If the changes are applicable to all then I will make changes in Project A, so that if I update Project B and Project C automatically they should get the changes.
But if any customization came for project level then I need to change in Project B only. It should not affect to Project A or C. Like this how can I handle all three projects using git.
Will it work with using branches.?
Thanks in Advance...
Use build variants in your code, instead of relying on multiple branches in git. This way, a single source code can be generated as multiple applications.
android {
compileSdkVersion ...
buildToolsVersion ...
defaultConfig {
applicationId "com.yourapp"
...
}
// Specify the build dimension and flavors
flavorDimensions "type"
productFlavors {
typeA {
dimension "type"
applicationIdSuffix '.typea' // Add this to differentiate the application ID
versionNameSuffix "-typea" // Add this to differentiate version naming
}
typeB {
dimension "type"
applicationIdSuffix '.typeb'
}
typeC {
dimension "type"
applicationIdSuffix '.typec'
}
}
}
It doesn't matter if your classes are in the same package, as long as your application ID differs, you can install multiple version of the app at the same time on your device.
To build each specific app, simply change the chosen variant in Android Studio.
For specific flavor implementation in your code, you can use BuildConfig.FLAVOR to check which flavor the current application is.
when (BuildConfig.FLAVOR) {
"typeA" -> {
// Do stuff for typeA app
}
"typeB" -> ...
"typeC" -> ...
}
Is there a way to tell Android we are developing and testing the application locally ? so I can write something like that in the code to execute specific code that has to be executed in case of a local development vs when the application is intended to be deployed and fetch the right remote data :
if (LOCALLY) {
MyLocalTools.xdebugIntegration();
...
}
...
And when the application is to be shared, i just have to turn a global option to mute all the local code ?
If by "local development", you mean debug builds, and by "intended to be deployed", you mean release builds, you can use BuildConfig.BUILD_TYPE to distinguish those build types, or use BuildConfig.DEBUG to distinguish between builds that are debuggable versus those that are not. Or, if you need a particular constant, use buildConfigField to add that custom field to BuildConfig.
Product flavors, cited in another answer, are designed for cases where you need two separate release builds (e.g., one with Google's in-app purchasing APIs, one with Amazon's in-app purchasing APIs).
You can use build flavor and build variants.
In your build.gradle you can define some flavors like follows:
productFlavors {
dev {
buildConfigField "String", "SERVICE_URL_BASE", "\"dev.example/rest\""
applicationId "development.example.app"
}
prod {
buildConfigField "String", "SERVICE_URL_BASE", "\"prod.example/rest\""
applicationId "com.example.app"
}
}
As you can see we have defined 2 flavor with different variables to use. In my case I have defined two different endpoints for rest services and different application id.
Then on the bottom left of Android Studio you can select which build variant use to launch your app. Build variants are the union of build flavors and build types (defaults build types are debug and release).
In your code you can access variables defined in build.gradle file like follows:
BuildConfig.SERVICE_URL_BASE
And you can access your build type with of flavor with something like this:
BuildConfig.FLAVOR
BuildConfig.BUILD_TYPE
Using these variables you can implement all the switch you desire
I developed a "template" application that I want to distribute on Google Play using different names and assets depending on the specific domain I'm targeting the app for (general, "domain1", "domain2", ...).
I have read in other posts that the first thing to do is to change the package name for each new application (in fact Google Play uses it as index, so it can NOT be repeated).
The easy solution I see is to create a new project and change the package name and assets, but this is quite "bloated". I'm wondering whether it's possible somehow to use a single AndroidStudio project to generate the "template application" and the "domain specific" ones.
You can Define product flavors in the build file like general , domain1 ,domai2, .....
...
android {
...
defaultConfig { ... }
signingConfigs { ... }
buildTypes { ... }
productFlavors {
general {
applicationId "com.buildsystemexample.app.general"
versionName "1.0-demo-general"
}
domain1 {
applicationId "com.buildsystemexample.app.domain1"
versionName "1.0-full-domain1"
}
...
...
}
}
...
As you see, all flavours will have different applicationId.
And moreover , you can have different resources or src or assets for your flavors as you want.
All you have to do is build the flavor you want from android studio.
Read more here. https://developer.android.com/tools/building/configuring-gradle.html