How does gradle handle multi modules with different support library v4 revisions?

Question

I have an Android project which depends on different modules and each modules depends on different revision of the android support-v4 library

1) My app also depends on the latest android support-v4 library (revision 21) so in this build.gralde I put a line like that:

dependencies {
            compile 'com.android.support:support-v4:21.0.0'
        }

2) Facebook SDK (v.3.15) module that also depends on the android support library v4, but revision 13 and its build.gradle file says:

dependencies {
        compile 'com.android.support:support-v4:13.0.+'
        compile files('../libs/bolts.jar')
    }

3) and one more module that, we can call Module3 in that case, also depends on the support-v4 but with a different revision than the other modules, like that:

dependencies {
        compile 'com.android.support:support-v4:19.0.+'
        compile files('../libs/bolts.jar')
    }

Questions:

1) How does gradle handle different support-v4 library revisions?

2) What does it do exactly?

3) What does it mean in terms of apk size?

Answer 1

In this case Gradle will fail the build (tested on my skin and I did not find other solutions) "Unfortunately" you have to use the same version of support on any module.

From docs.gradle.com:

Gradle offers the following conflict resolution strategies:

• Newest: The newest version of the dependency is used. This is Gradle's default strategy, and is often an appropriate choice as long as versions are backwards-compatible.

• Fail: A version conflict results in a build failure. This strategy requires all version conflicts to be resolved explicitly in the build script. See ResolutionStrategy for details on how to explicitly choose a particular version.

While the strategies introduced above are usually enough to solve most conflicts, Gradle provides more fine-grained mechanisms to resolve version conflicts:

• Configuring a first level dependency as forced. This approach is useful if the dependency in conflict is already a first level dependency. See examples in DependencyHandler.

• Configuring any dependency (transitive or not) as forced. This approach is useful if the dependency in conflict is a transitive dependency. It also can be used to force versions of first level dependencies. See examples in ResolutionStrategy

• Dependency resolve rules are an incubating feature introduced in Gradle 1.4 which give you fine-grained control over the version selected for a particular dependency.