I have a library project and a application. I\'d like to have 2 product flavours (store, dev) for both library and application. When I build the store<
In your library you need to tell gradle to build every time every variant:
android {
publishNonDefault true
}
Then in your application, since recently I guess, you can do this:
dependencies {
(...)
devCompile project(path: ':lib', configuration: 'devDebug') // or 'devRelease'
storeCompile project(path: ':lib', configuration: 'storeRelease') // or 'storeDebug'
}
Found in the official documentation under Library Publication.
Edit:
Since version 0.14.3 (2014/11/18), you can now have Flavor-buildType-Compile directive as well:
In your build.gradle before the android {} scope add the following:
configurations {
devDebugCompile
devReleaseCompile
storeDebugCompile
storeReleaseCompile
}
Then you can declare and use different versions of your library per Flavor-BuildType:
dependencies {
(...)
devDebugCompile project(path: ':lib', configuration: 'devDebug')
devReleaseCompile project(path: ':lib', configuration: 'devRelease')
storeDebugCompile project(path: ':lib', configuration: 'storeDebug')
storeReleaseCompile project(path: ':lib', configuration: 'storeRelease')
}
Edit:
Dependency management between modules has changed since Android Gradle Plugin 3.0.0. It automatically tries to matches flavours between your app and the libraries/modules it depends on.
See the documentation for the whole explanation!
To define specific dependency for each flavor you can use "nameOfTheFlavorCompile" instead of "compile"
dependencies {
storeCompile project(':lib')
}
I had a similar issue a while ago, what happens is that the compiler ignores product flavors for the library project. Moreover, even when you add more build types, it keeps looking for and compiling release/debug sources.
The reason is simple:
The compiler will never look for anything you put in the store directory of your library project. So, you need to find a way around it.
One way around it would be to include both implementations with a level of abstraction in your library (through interfaces, multiple constructors, etc), and then let your app project decide which part of the library to run. If you use proguard, it will automatically get rid of the unneeded code, if it is decoupled well enough (and possibly so even if it is not).