This question already has answers here:
Reference different assets based on build flavor
(2 answers)
Closed 3 years ago.
I can not get product flavours working. I have this gradle
apply plugin: 'com.android.application'
android {
defaultConfig {
minSdkVersion 14
targetSdkVersion 24
compileSdkVersion 27
}
signingConfigs {
release {
}
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
signingConfig signingConfigs.release
}
}
repositories {
maven { url "https://jitpack.io" }
}
flavorDimensions "dim1", "dim2", "dim3"
productFlavors {
flavor1 {
dimension "dim1"
applicationId "com.example.dim1.app"
}
flavor3 {
dimension "dim2"
applicationId "com.example.dim2.app"
}
flavor3 {
dimension "dim3"
applicationId "com.example.dim3.app"
}
}
sourceSets {
flavor1 {
java.srcDirs = ["W:/android-studio-projects/sharedid/app/src/main/java/"]
manifest.srcFile "W:/android-studio-projects/sharedid/app/src/example1/AndroidManifest.xml"
assets.srcDirs = ["W:/android-studio-projects/sharedid/app/src/example1/assets/"]
resources.srcDirs = ["W:/android-studio-projects/sharedid/app/src/main/res/", "W:/android-studio-projects/sharedid/app/src/example1/res/"]
}
flavor2 {
java.srcDirs = ["W:/android-studio-projects/sharedid/app/src/main/java/"]
manifest.srcFile "W:/android-studio-projects/sharedid/app/src/example2/AndroidManifest.xml"
assets.srcDirs = ["W:/android-studio-projects/sharedid/app/src/example2/assets/"]
resources.srcDirs = ["W:/android-studio-projects/sharedid/app/src/main/res/", "W:/android-studio-projects/sharedid/app/src/example2/res/"]
}
flavor3 {
java.srcDirs = ["W:/android-studio-projects/sharedid/app/src/main/java/"]
manifest.srcFile "W:/android-studio-projects/sharedid/app/src/example3/AndroidManifest.xml"
assets.srcDirs = ["W:/android-studio-projects/sharedid/app/src/example3/assets/"]
resources.srcDirs = ["W:/android-studio-projects/sharedid/app/src/main/res/", "W:/android-studio-projects/sharedid/app/src/example3/res/"]
}
}
}
dependencies {
api 'com.google.android.gms:play-services-maps:15.0.0'
api 'com.google.android.gms:play-services-location:15.0.0'
api 'com.android.support:appcompat-v7:27.1.1'
api 'com.github.PhilJay:MPAndroidChart:v2.0.8'
}
...
When I got to "Build | Select variant" I can only select
Module:app
Build Variant:flavor1Flavor2Flavor3Debug,flavor1Flavor2Flavor3Release
I would have liked to get
the following build variants: flavor1Debug,flavor2Debug,flavor3Debug,flavor1Release,flavor2Release,flavor3Release
I have tried "File | Sync project with gradle file"
...
I get this error
Caused by: java.lang.RuntimeException: Cannot read packageName from
W:\android-studio-projects\sharedid\app\src\main\AndroidManifest.xml
I have tried to both
have no such file (hoping it would take the product flavor one?)
have the "main" manifest only define shared stuff between all product flavors
Just try like below,
flavorDimensions "dim1"
productFlavors {
flavor1 {
dimension "dim1"
applicationId "com.example.dim1.app"
}
flavor3 {
dimension "dim1"
applicationId "com.example.dim2.app"
}
flavor3 {
dimension "dim1"
applicationId "com.example.dim3.app"
}
}
For more details about build variant see this link
I think there are two unrelated problems :
Currently you have 2 build types (the automatically created debug and release) and 3 dimensions (dim1, dim2 and dim3), each one having 1 variant (flavor1 for dim1, flavor2 for dim2, ...)
this gives at most :
2 * 1 * 1 * 1 = 2 combinations
You should switch to 2 build types and 1 dimension (say dim1) having 3 variants (flavor1, flaver2 and flavor3) to have :
2 * 3 = 6 apks
You should have a main manifest. Unlike other resources the manifest is not simply overriden but merged from multiple sources (see Merge Multiple Manifest Files for more details).
It should at least contains a package name (possibly different from the final applicationId(s)) as explained by this note from Configure Product Flavors :
Note : You still need to specify a package name using the package attribute
in the main/ manifest file. You must also use that package name in
your source code to refer to the R class, or resolve any relative
activity or service registration. This allows you to use applicationId
to give each product flavor a unique ID for packaging and
distribution, without having to change your source code.
I would have liked to get
the following build variants:
flavor1Debug,flavor2Debug,flavor3Debug,flavor1Release,flavor2Release,flavor3Release
For this, you need to define the same dimension for all flavors.
I get this error
Caused by: java.lang.RuntimeException: Cannot read packageName from
W:\android-studio-projects\sharedid\app\src\main\AndroidManifest.xml
You get this error because the path is not reachable.
Just think, how can app find W: when it is running?
So, you need to use a relative path here.
Also from official documentation (https://developer.android.com/studio/build/build-variants#configure-sourcesets):
If you have sources that are not organized into the default source set
file structure that Gradle expects, as described above in the section
about creating source sets, you can use the sourceSets block to change
where Gradle looks to gather files for each component of a source set.
You don't need to relocate the files; you only need to provide Gradle
with the path(s), relative to the module-level build.gradle file,
where Gradle should expect to find files for each source set component
Related
I have an Android application that has two flavors, free and premium. I would like to create another flavor, flavorExt, that is based on the free flavor but has some additional functionality. I have done this using the sourceSets option in gradle, like the following:
sourceSets {
freeExt {
java.srcDirs = sourceSets.free.java.srcDirs
res.srcDirs = sourceSets.free.res.srcDirs
resources.srcDirs = sourceSets.free.resources.srcDirs
}
}
Now I would like to add some additional functionality to the freeExt flavor but I do not know if this is possible and if so, how it can be done. I have created the flavor source folder as app/src/freeExt/java/... and added the necessary files in it. I also added the following line in the sourceSets entry in gradle without success:
java.srcDirs = sourceSets.free.java.srcDirs
Is what I am trying to do possible in gradle? If so, how can it be done?
I would recommend creating a second flavor dimension for the added functionality. You can find the documentation on multiple flavor dimensions here.
Your build.gradle would look something like this:
android {
flavorDimensions "tier", "extras"
productFlavors {
free {
dimension "tier"
...
}
full {
dimension "tier"
...
}
withExtras {
dimension "extras"
...
}
noExtras {
dimension "extras"
...
}
}
}
The Android Gradle Plugin will generate variants using the cross-product of each flavor in each dimension. Thus you will end up with a freeWithExtras, freeNoExtras, fullWithExtras and fullNoExtras. You don't necessarily need to release all four variants.
I need to create a demo flavor in android studio for an app. In my app level gradle file i have created another flavor called demo and the default flavor of full of course. It looks like this:
apply plugin: 'com.android.application'
android {
compileSdkVersion 22
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "com.example.uen229.myapplication"
minSdkVersion 17
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
productFlavors {
demo {
applicationId "com.buildsystemexample.app.demo"
versionName "1.0-demo"
}
full {
applicationId "com.buildsystemexample.app.full"
versionName "1.0-full"
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
}
and here is a image of my project structure in which I have created a demo flavor directory:
Now onto the issue. I have two classes called Hello.java. Both are in there respective flavors and print different things. I'll show you both files now:
import android.util.Log;
/** this is from demo flavor directory**/
public class Hello {
Hello(){
Log.v("","hello from demo");
}
public String getName();
return "im from demo";
};
}
And here is the other Hello:
package com.example.uen229.myapplication;
import android.util.Log;
/** this is from full or main flavor directory**/
public class Hello {
Hello(){
Log.v("", "hello from main");
}
public String getName(){
return "im from main";
};
}
notice how the first hello.java does not have package, even if i had a package the IDE wont compile. look at this photo:
Now finally lets look at mainActivity.java to see that when i switch build variants it only does a toast for "im from main" but i need it to print 'im from demo" if i use the demoDebug build variant. If i switch the build variant to demoDebug it still prints "im from main". can anyone help :
public class MainActivity extends ActionBarActivity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Hello h = new Hello();
Toast.makeText(this, h.getName(), Toast.LENGTH_LONG).show();
}
}
UPDATE
From stackoverflow it says:
If you want to have a different version of the same class in the two
flavor you'll need to create it in both flavors.
src/flavor1/java/com/foo/A.java
src/flavor2/java/com/foo/A.java
And then your code in src/main/java can do:
import com.foo.A
depending on the flavor selected, the right version of com.foo.A is
used.
This is what I want to accomplish with the Hello class
I think you can't have same class in main flavor and your other flavor. you should just create another flavor, then move your Hello class from main flavor to that new flavor. this rule is just for .java files. I mean you can have an xml file in main flavor and another version in your custom flavor but you can't do this with java files.
here is a useful link with further explanation.
I would advice to create 3 source sets:
main - which would contain common classes
demo - contains demo specific classes
pro - contains classes for pro versions
and declare them using:
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src/main/java']
res.srcDirs = ['src/main/res']
assets.srcDirs = ['src/main/assets']
}
pro {
manifest.srcFile 'src/pro/AndroidManifestPro.xml'
java.srcDirs = ['src/main/java', 'src/pro/java']
}
demo {
manifest.srcFile 'src/oldlite/AndroidManifestDemo.xml'
java.srcDirs = ['src/main/java', 'src/demo/java']
}
}
P.S. not really sure about syntax of java.srcDirs content - please double check yourself
I was able to override classes but the key was not to include the class in my main folder.
So the fullDebug (i.e. main folder) build variant will never get run. Always run a flavor and not the main folder. The main folder will just be used to keep common things in it.
In my case I had a demo for USA and another country (demo and demo_us)and I needed two flavors. I'll always build for either of the two and won't build main.
From the image you can see I made all my package names to be the same: like com.example.******.myapplication. Since they all have the same package name in the MainActivity you just import Hello.java with that package name and it will pick the right variant at build time.
For resources it looks like it's different and it will override naturally but java class files have to do this way.
Information
So I have this project structure that looks like this:
Project root:
| Resources-module (uses the packagename: com.derk.application.resources)
-+ src
---+ main
-----+ res
| Core-module (uses the packagename: com.derk.application)
-+ src
---+ main
-----+ src
| Brand-module (uses whatever packagename of the customer domain)
Resources-module contains the res files.
Core contains a git-module that contains code for a code-base we keep updated.
Brand contains build.gradle where I setup the packagename of our customer and bind the main/res directory to the resource-module main/res, and then the main/src to the core-module main/src folder.
Like this:
android.sourceSets.main {
manifest.srcFile "src/main/AndroidManifest.xml"
res.srcDirs = ["$rootDir/resources-module/src/main/res"]
java.srcDirs = ["$rootDir/core-module/src/main/java", "src/main/java"]
}
}
I do not wish to alter the Core-module sources under any circumstances without it being pushed up to the master repository, meaing I only make global changes/fixes for all projects that uses core-module. This is why i tried this structure out.
The sourcefiles in the core-module will loads the imports
import com.derk.application.resources.R;
import com.derk.application.resources.BuildConfig;
to handle the resource generated content from gradle/idea
Since Brand-module is due to having packagename changes, I have to use some sort of middlemodule that holds the R and BuildConfig for easy deployment, so that the core-sources indeed never have local modifications.
When i try to refresh gradle for the brand-module, i do not get any issues, and android studio seems to find the R.java and BuildConfig.java just fine in the com.derk.application.resources when I check out the linkage in Android Studio
HOWEVER
When I try to run Brand-module, i get:
"Execution failed for task ':core-module:compileReleaseJava'."
and it now instead shows me:
Error:(20, 39) error: package com.derk.application.resources does not exist
even thought I have added
dependencies {
compile project(':resources-module')
}
to the build.gradle of core-module.
So the question is:
How do I setup gradle to handle this kind of cross-module dependency?
Keep in mind, I do not wish to alter the packagename for the core-module imports for each new project I setup, because we get local changes made to a gitmodule that is used for several projects.
/.ps
Currently i can without problem run module resources-module and have the app running, with the static packagename i've chosen for it. But that is also the problem, I want to keep it static, and hence that is why i introduced the third module.
You do that in the wrong way. What you are trying to achive is implementing a normal library module (which you use for every customer). Then you can create a new Module from the type application which uses the shared module. In that case you don't need to mess around with the path of the shared module.
For the case that your shared module is in another directory than the project root you can use this settings.gradle:
include ':CustomerX', ':SharedModule'
project(':SharedModule').projectDir = new File('../../some/where/else')
If not you can omit the last line.
When you keep a old directory structure you should try using this build.gradle:
apply plugin: 'com.android.library'
android {
compileSdkVersion 9
buildToolsVersion '21.0.1'
defaultConfig {
minSdkVersion 9
targetSdkVersion 21
}
sourceSets {
main {
assets.srcDirs = ['assets']
res.srcDirs = ['res']
aidl.srcDirs = ['src']
resources.srcDirs = ['src']
renderscript.srcDirs = ['src']
java.srcDirs = ['src']
manifest.srcFile 'AndroidManifest.xml'
}
}
}
dependencies {
// just as example
compile 'com.android.support:support-v4:21.0.2'
}
You customers build.gradle should look e.g. like this:
apply plugin: 'com.android.application'
android {
compileSdkVersion 21
buildToolsVersion '21.0.1'
defaultConfig {
minSdkVersion 9
targetSdkVersion 21
signingConfigs {
release {
storeFile file("your.keystore")
storePassword 'pwd1'
keyAlias "alias"
keyPassword 'pwd2'
}
}
buildTypes {
debug {
debuggable true
minifyEnabled false
shrinkResources false
}
release {
debuggable false
jniDebuggable false
signingConfig signingConfigs.release
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
dependencies {
// dependencies of the main project
compile 'com.android.support:support-v4:21.0.0'
compile 'com.android.support:appcompat-v7:21.0.0'
compile project(':SharedModule')
}
I'm trying to make a batch file with some commands, so once it runs, it will change some strings in the files, build the project and generate the APK signed.
The strings I need to change are:
- The package name (com.company.project)
- Some images (like icons, splash screen, ...)
- some irrelevant string that are specific from the app.
For the last 2 things I know how to do it, but for the package name I feel there is something wrong about just find and replace all the occurrences of that string in the root folder of the app (including subdirectories).
Is there any way or command that ant has for doing this?
Also I ran into an issue while running the command ant release.
I went to my root folder, ran the command and it gets errors.
So I had to go to eclipse, clean the project and let it autobuild (with no generation of APK since it does that when you try to run it on a device) so at that point my bin folder just contains the folders: classes, dexedLibs, res and the Manifest.xml file.
Then I can go to the CL and run ant release.
So is there any way to do all this from CL? Something like clean and build so I can run ant release command after with no issues?
NOTE: for find and replace I use an .exe called FNR that does the job
EDIT:
I'm now using gradle and can build changing the package name but there is still a few things I want to do in the build.gradle file and can't make it work.
This is build.gradle:
task("hello"){
println "Hello world!!"
}
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.8.+'
}
}
apply plugin: 'android'
dependencies {
compile fileTree(dir: 'libs', include: '*.jar')
}
android {
compileSdkVersion 19
buildToolsVersion "19.0.3"
productFlavors {
flavor1 {
packageName "com.testCompany.testProject"
}
}
signingConfigs {
release {
storeFile file("keystore/android.keystore")
storePassword 'blah blah'
keyAlias "blah blah"
keyPassword 'blah blah blah'
}
}
buildTypes {
flavor1 {
zipAlign true
sourceSets {
main {
signingConfig signingConfigs.release
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
}
}
}
}
I am pretty sure I'm doing things wrong.
So I want to:
- Change some strings in the res/strings.xml file.
- Change the icon/png files in the res/drawable.... folder for custom ones.
I have completely no idea of how to do it. I tried:
buildTypes{
flavor1{
copy{
from('src/res/'){
include '**/*.xml'
filter{String line -> line.replaceAll(string_to_be_replaced, replaced_string)}
}
into '$buildDir/res'
}
}
}
but nothing
The strings I need to change are: - The package name (com.company.project)
If you are changing these things based upon whether this is a debug build or a release build, you can specify a suffix on the package name for a build type:
android {
buildTypes {
debug {
packageNameSuffix ".debug"
}
}
}
Or, if you are changing these things for anything else, you can create product flavors and replace the package name per flavor:
android {
productFlavors {
flavor1 {
packageName "com.example.flavor1"
}
flavor2 {
packageName "com.example.flavor2"
}
}
}
Some images (like icons, splash screen, ...) - some irrelevant string that are specific from the app.
You can create source sets for build types (e.g., src/debug/) or product flavors (e.g., src/flavor1/) and have replacement versions of resources in them. That will handle your images, as well as your "irrelevant string" if you define it as a string resource.
Source sets can also have Java code, though that gets incrementally more complex, so I would recommend that you use the string resources and replacement resources instead.
I have created simple test project: the goal is to show the message 'hello' by pressing a button on the screen. The first flavor build should write the message to the system log. The second flavor build should show a toast with message. How can this be achieved using gradle please?
My build.gradle:
apply plugin: 'android'
android {
compileSdkVersion 19
buildToolsVersion "19.0.1"
defaultConfig {
minSdkVersion 14
targetSdkVersion 19
versionCode 1
versionName "1.0"
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
productFlavors {
toast {
}
log {
}
}
sourceSets {
main {
java.srcDirs = ['src/main/java', 'src/log/java']
}
toast {
java.srcDirs = ['src/main/java', 'src/toast/java']
}
}
buildTypes {
release {
runProguard false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar', '*.aar'])
}
File structure:
Flavor log contains single class Messenger with method showMessage(Context context, CharSequence text) and prints text using Log.i(tag, msg)
Flavor toast contains single class Messenger with method showMessage(Context context, CharSequence text) and shows toast with some text.
Main sources don't contain this class.
Why does the error duplicate class:com.test.flavortest.Messenger appear? Each flavor has a set of different non-crossing source paths?
Full sample project, zipped
In your sourcesets definition, you seem to be adding the log sources to main:
sourceSets {
main {
java.srcDirs = ['src/main/java', 'src/log/java']
}
toast {
java.srcDirs = ['src/main/java', 'src/toast/java']
}
}
main is the default sourceset included in all flavors. This would cause a duplicate class (Messenger) being loaded when building the toast flavor.
Try specifying the log and toast sourcesets only:
sourceSets {
log {
java.srcDirs = ['src/main/java', 'src/log/java']
}
toast {
java.srcDirs = ['src/main/java', 'src/toast/java']
}
}
Your file structure seems to match the default, so an even better solution would be to remove the sourcesets block entirely. src/main/java is included by default, and then src/flavor/java is added afterwards automatically.
Use assembleToast / assembleLog to Build an specific Flavour.
Same for installToast e.g
The global assemble will use every File in the directory.
All source code in the java/ directories are compiled together to generate a single output.
Note: For a given build variant, Gradle throws a build error if it encounters two or more source set directories that have defined the same Java class. For example, when building a debug APK, you cannot define both src/debug/Utility.java and src/main/Utility.java. This is because Gradle looks at both these directories during the build process and throws a 'duplicate class' error. If you want different versions of Utility.java for different build types, you can have each build type define its own version of the file and not include it in the main/ source set.