Blog Infos

When developing a modularized Android project it is expected to have many modules and some of which are interdependent. However, as the project grows, it becomes harder and harder to keep track of the modules location and names, which can lead to situations where one have to spend some amount of time remembering this info, or even to compilation errors.

It is very common to have similar lines in our build.gradle when declaring the project dependencies:

dependencies {

Fortunately, in Gradle 7.0, the one required with Android Studio 2020.3.1 Artic Fox, a new type-safe project accessors was included to make out life easier.

Setting up

First of all, keep in mind that this feature is experimental at the moment. At the time that this article was written, the latest stable version for Gradle is 7.2, but this feature is expected to become stable in future releases.

In order to enable this feature in our project, we need to add the following line to our setting.gradle(kts) file:

Accessing the modules

After adding the experimental line and syncing Gradle files, it is now possible to access the modules in a new way. Now, instead of hard-coding the modules location and names, we have a safer way, including IDE auto-complete. Let’s take on the new approach:

dependencies {

IDE auto-complete for Gradle modules


Another great addition that this feature brings to the table is smarter compilation errors. Previously, if some module were renamed or moved, the script would fail only when compiling the app. When using the type-safe project accessors, the error will now shown up with more context:

Compilation error when Gradle modules is not correct

General tips

All the project accessors are mapped from the project path, this means that if a module path is :libraries:commons:ui, then the project accessor will be projects.commons.ui and so on.

Also, when a module was created with kebab case ( some-module-api) or snake case ( some_module_api), both will be converted to camel case when using the accessors ( projects.someModuleApi).


Job Offers

Job Offers

    Senior Android Engineer – Big Release Team

    Zalando SE
    • Full Time
    apply now

    Lead Android Engineer

    • Full Time
    apply now

    Developer (m/w/d) Backend/ Mobile

    Payback GmbH
    Cologne, Germany
    • Full Time
    apply now
Load more listings



What’s next?

If you want to take a deep dive in the code, please take a look in the Pull Request submitted to Alkaa in order to update all the hard-coded references to project accessors.

During my tests, I only was able to make the IDE auto-complete to work when using build.gradle.kts files. There is support for regular build.gradle files however it seems that it does not have the same powerful support like its .kts counterpart.

Final thoughts

We’ve been trying for years to improve the dependency handling with Gradle, and the type-safety accessors are a huge step towards this goal. The type-safety and the auto-completion it brings to the table help a lot, leading to fewer errors and speeding up the development while we focus in what really matters: our application.

Personally, I’m very excited with all the new changes that are coming to Gradle in the last years. It feels that the team is really listening to our comments and acting to make our life easier. 😊

External reference

For more information about the new type-safe project accessors, I recommend the official docs from If you find any bugs while using this feature in Android development, please open an Issue Tracker to help the team and the community.

Thanks a lot for reading my article. ❤️

Thanks to Bruno Kenji Tiba.




The ABC of Modularization for Android in 2021

Modularization is not a recent topic at all. This concept have been around us…

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.