A Bit of Gradle Housekeeping
2021.09.01. 20h • Márton Braun
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.
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:
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:
jvmTarget = '1.8'
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:
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
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:
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
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:
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.
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!
You might also like...
Another year over, a new one's almost begun. Here's a brief summary of what I've done in this one.
Introducing a new library to conveniently require values from common Android types.
StateFlow behaves as a state holder and a Flow of values at the same time. Due to conflation, a collector of a StateFlow might not receive all values that it holds over time. This article covers what that means for your tests.
Have you ever encountered APIs that show warnings or errors when you use them, saying that they're internal or experimental? In this guide, you'll learn everything you need to know about opt-in APIs in Kotlin: how to create and use them, and all their nuances.