Gradle Dependency Management
If you are using single module architecture in your project, there’s no problem. But multi-module Android projects are the primary way to develop an Android App now, and it’s highly recommended to use this way to take advantage of performance improvements with Android Gradle Plugin (AGP) 3+. However, when the module size increases, we encounter a big issue - dependency management in each module.
Here we are going to introduce some solutions for Gradle dependency management.
Manual management
Not a recommended way to do, you might see there are many duplicated dependency code in different modules, for example:
Module_A/build.gradle
1 | implementation "com.android.support:support-annotations:27.0.2" |
Module_B/build.gradle
1 | implementation "com.android.support:support-annotations:27.0.2" |
This is not a good way and is painful. You will need to dive into different modules and copy-paste almost the same dependencies for each module.
Google Ext Section
This is the way recommended by Google. First of all, we need to define a project-level build.gradle and put the version and library information inside.
Project-level build.Gradle
1 | buildscript {...} |
After that, we need to define the module-level build.gradle file,
1 | android { |
By using this way, it’s very convenient to manage all dependencies in a single file. That’s a considerable improvement.
Kotlin buildSrc
When I was at Cruse, we switched our dependency management to this way. You need to create a buildSrc
module with Kotlin code to manage dependencies. The most significant benefit you can gain is leveraging the IDE completion support when importing a dependency.
So, here are steps to use this way.
Create a
buildSrc
moduleCreate
build.gradle.kts
file to enable this feature.1
2
3plugins {
`kotlin-dsl`
}Create your dependency file, for example, ProjectDependency.kt
1 | object Versions { |
After creating those files, we can start using those defined dependencies in our module-level build.gradle files.
Gradle Version Catalog
Based on the Gradle document, central declaration of dependencies is an incubating feature. It requires the activation of the VERSION_CATALOGS
:
1 | enableFeaturePreview('VERSION_CATALOGS') |
Here is an example to show how to define your version catalog:
settings.gradle.kts
1 | dependencyResolutionManagement { |
Based on this example, you can find the rules as following:
1 | dependencyResolutionManagement { |
It enables you to define your alias and bundle at the top level. You can use them in different modules like, libs.alias.sample
or bundle.bundle.set
. Version catalogs support autocompletion in the IDE through their type-safe accessors generated by Gradle.
Gradle also supports TOML for the version catalog feature. You would need to create a file called libs.versions.toml
in the gradle
subdirectory of the root build, then a catalog will be automatically declared with the contents of this file. The TOML file consists of 4 major sections:
- the
[versions]
section is used to declare versions that dependencies can reference - the
[libraries]
section is used to declare the aliases to coordinates - the
[bundles]
section is used to declare dependency bundles - the
[plugins]
section is used to declare plugins
Here is an example for this file:
1 | [versions] |
The usage is very similar when you define those parameters in your gradle files. For example,
1 | // access version section |
That’s it. Enjoy the coding.
#Android #Android/Gradle/VersionCatalog