Sharing Gradle Configuration in Multi-Module Android Projects

Sam Edwards
Oct 31 · 2 min read

This post originally appeared on my personal blog https://handstandsam.com

In my work with Android projects, using multiple modules helps us split apart our code into logical components. They also can enable faster incremental builds, and more modular code. One problem with multi-module projects is that there is a lot of verboseness of configuration. This post shows you a method of sharing common configuration between your Android Library modules in order to cut down on boilerplate Gradle configuration.

I made this change in a PR in my ShoppingApp project on GitHub and ended up deleting a net 90 lines of code over 7 library modules.

“Common Gradle Config for Android Library Modules” GitHub dashboard
“Common Gradle Config for Android Library Modules” GitHub dashboard

apply from: “____.gradle”

You can add the contents of another Gradle file into your current one by using “apply from:” and specifying the file whose content you want to add.

apply from: “$rootProject.projectDir/android-library.gradle”

$rootProject.projectDir

Modules can exist in different directory structures, so by leveraging the $rootProject.projectDir property, we specify paths based on the root project directory.

Original Library Module build.gradle

apply plugin: ‘com.android.library’
apply plugin: ‘kotlin-android’
android {
compileSdkVersion Versions.compile_sdk
defaultConfig {
minSdkVersion Versions.min_sdk
targetSdkVersion Versions.target_sdk
versionCode 1
versionName “1.0”
testInstrumentationRunner
“android.support.test.runner.AndroidJUnitRunner”
}
}
dependencies {
implementation project(Modules.models)
implementation Libs.kotlin_std_lib
}

Resulting Library Module build.gradle

apply from: “$rootProject.projectDir/android-library.gradle”dependencies {
implementation project(Modules.models)
implementation Libs.kotlin_std_lib
}

Shared Gradle File

apply plugin: ‘com.android.library’
apply plugin: ‘kotlin-android’
android {
compileSdkVersion Versions.compile_sdk
defaultConfig {
minSdkVersion Versions.min_sdk
targetSdkVersion Versions.target_sdk
versionCode 1
versionName “1.0”
testInstrumentationRunner
“android.support.test.runner.AndroidJUnitRunner”
}
}

If You Do Something 3+ Times, Extract Out Functionality

Whenever it’s possible and makes sense, use common configuration to reduce boilerplate. This same rule applies if you are writing code, or writing Android Gradle configuration. This post shares an “easy win” that you may be able to use to help better manage your multi-module project. There is so much more you can do to clean up your builds by leveraging buildSrc where you can write in Kotlin, Java, or Groovy, but that’s for another post.


DISCLOSURE STATEMENT: © 2019 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.

Capital One Tech

The low down on our high tech from the engineering experts at Capital One. Learn about the solutions, ideas and stories driving our tech transformation.

Sam Edwards

Written by

I create pieces of the web at @HandstandTech. I'm a fan/user of #Java, #AppEngine, #Android, #JavaScript, #Foursquare, #VirginiaTech Alumni

Capital One Tech

The low down on our high tech from the engineering experts at Capital One. Learn about the solutions, ideas and stories driving our tech transformation.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade