A Bit of Gradle Housekeeping

While cleaning is traditionally a spring activity, let me invite you to do it at the end of summer this time around.

Note: Yes, I’m still using Groovy because I never found a compelling reason to upgrade to Kotlin DSL 🤷‍

Something I’m quite enthusiastic about is having the simplest and most default Gradle configuration for an Android project that you can possibly have.

Why? Because simple and boring configuration is great! The more configuration you have in these files, the more custom your setup, the harder it is to navigate.

• When something weird is happening in your project, having simpler project setup avoids a lot of potential headache when you need to figure out what’s going on.
• When someone new joins the project or starts working with the project configuration files, a simpler setup will make their lives easier too.

In this article, we’ll look at various bits of configuration that you might have in your build files that you don’t actually need anymore, or can replace with something simpler.

Build tools version

I’ll start with a classic that you should have removed four years ago when version 3.0.0 of the Android Gradle Plugin was released. Despite that, it still lingers around in many projects.

android {
    buildToolsVersion "30.0.3"
}

This version number is set by default - feel free to simply remove it from your build config!

Java version settings

Continuing with a more recent change, if you’re on AGP 4.2 or later, you no longer have to specify that you want to target version 8 of the Java language (which gives you desugaring for various features like lambdas and method references).

This means you can remove this config, if you have it in your build files:

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

Kotlin JVM target settings

On a very similar note, we used to have to specify the JVM version that the Kotlin compiler should target explicitly (as the default was 1.6). Since Kotlin 1.5 however, the default value for this is 1.8, which means you can remove this config as well:

android {
    kotlinOptions {
        jvmTarget = '1.8'
    }
}

*SdkVersion

Something not to completely remove but to slightly simplify is the various SDK versions you specify in a project. Traditionally, you have probably used the following properties to set these values:

android {
    compileSdkVersion 31

    defaultConfig {
        minSdkVersion 21
        targetSdkVersion 31
    }
}

However, since AGP 4.1.0, these are deprecated and should be replaced with variants that no longer have the Version postfix. So, for example, minSdkVersion is now just minSdk:

android {
    compileSdk 31

    defaultConfig {
        minSdk 21
        targetSdk 31
    }
}

The src/main/kotlin source set

Back to things you can remove, let’s talk a bit of Kotlin. If you prefer using the src/main/kotlin folder instead of the src/main/java folder to store your source files (because you’re just that enthusiastic about using the language), you probably have configuration in your build files that resembles something like this:

sourceSets.all {
    it.java.srcDir "src/$it.name/kotlin"
}

This simply adds the folder in question as a source set where files will be used as compilation sources.

The good news is that since version 7.0.0 of the Android Gradle Plugin, you no longer need this. kotlin source folders are just supported by default!

Kotlin standard library dependency

Let’s wrap it up with a final Kotlin tip. The classic Kotlin Android project setup includes this variable set in the top level build.gradle file:

buildscript {
    ext.kotlin_version = "1.5.30"
}

And then a reference to it in the module level build.gradle file, where the Standard Library is included:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}

However, since Kotlin 1.4.0, including the Kotlin Gradle plugin automatically adds the Kotlin Standard Library as a runtime dependency to your modules (since you wouldn’t want to use the language without its Standard Library anyway).

It will include the correct version based on the module’s properties, matching the version of the plugin, the platform you’re running on, and the JVM target you have configured.

This means that you can remove the explicit dependency on the stdlib from your build files, and as a consequence, you can likely remove the kotlin_version variable as well.

Conclusion

Thanks for participating in this quick late summer project cleaning initiative. I hope you got to create a quick and simple PR to make your project config a bit leaner. See you next time!