Gradle: add dependency for a specific flavour of the library

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:

• Product flavors are not supported for the library plugin.
• The only build types supported seem to be debug and release.

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).