Share external dependencies between modules in Android Studio

Question

I'm trying to share 2 external dependencies between 2 modules in Android Studio. The 2 dependencies are Twitter Core and Twitter4j (a Twitter library extension I'm experimenting with).

Here is the project structure:

Root project 'cineios-test'
+--- Project ':app'
\--- Project ':cineio-broadcast-android-sdk'

I set up the dependencies in my app build.gradle file:

apply plugin: 'com.android.application'
apply plugin: 'io.fabric'

buildscript {
    repositories {
        maven { url 'https://maven.fabric.io/public' }
    }

    dependencies {
        classpath 'io.fabric.tools:gradle:1.+'
    }
}

repositories {
    maven { url 'https://maven.fabric.io/public' }
}


android {
    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
        applicationId "com.example.lgorse.cineios_test"
        minSdkVersion 18
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    packagingOptions{
        exclude 'META-INF/LICENSE.txt'
    }
}


dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:21.0.3'
    compile project(':cineio-broadcast-android-sdk')
    //compile project(':cineio-broadcast-android')
    //compile 'io.cine:cineio-broadcast-android-sdk:0.0.9'
    compile ('org.twitter4j:twitter4j-stream:4.0.2'){
        transitive = true;
    }
    compile('com.twitter.sdk.android:twitter:1.1.1@aar') {
        transitive = true;
    }

}

Here is the build.gradle file for the module, which is cineios-android-sdk:

apply plugin: 'android-library'

android {
    compileSdkVersion 19
    buildToolsVersion '19.1.0'
    defaultConfig {
       // applicationId 'io.cine.android'
        minSdkVersion 18
        targetSdkVersion 19
        versionCode 11
        versionName '0.0.11'
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    productFlavors {
    }
}

dependencies {
    compile 'com.google.guava:guava:16.0'
    compile 'com.loopj.android:android-async-http:1.4.5'
    compile 'com.android.support:appcompat-v7:20.0.0'
    compile 'com.android.support:support-v4:20.0.0'


}

Finally here is settings.gradle:

include ':app', ':cineio-broadcast-android-sdk'
project(':cineio-broadcast-android-sdk').projectDir = new File('cineio-broadcast-android/cineio-broadcast-android-sdk')

I know there are answers on SO but they refer adding local libraries as modules - but since these dependencies are remote I'm not sure how to adapt the hints to this situation.

I did try adding the dependencies to the other module (cineios-android) but a) it seems ridiculous to double them up like that and b)that would imply registering a new app in the Twitter API, which will probably lead to errors.

Answer 1

The correct approach really is to specify the dependencies in both the main app and the module.

I did try adding the dependencies to the other module (cineios-android) but a) it seems ridiculous to double them up like that and

There's really nothing ridiculous about it. Don't think of it as trying to "share" the dependency between the main app and the module. Look at it this way: your module depends on Twitter4j and Twitter Core. If you were to reuse that module in a different application, the module should be self-contained and should be able to specify its own dependencies without the parent project needing to set them up. Making all its dependencies explicit does this.

If the parent app also depends on Twitter4j and Twitter Core, and if you use the Maven Coordinate-style remote dependency specs as you have, the build system will ensure that only one copy actually gets linked into the app, so everything will be okay.

b)that would imply registering a new app in the Twitter API, which will probably lead to errors.

I'm not familiar with how that works, so I can't comment on it other than to say that if their API is well designed, hopefully just including the library shouldn't imply something like that. If you're having problems, clarify your question or ask a new one.