Be Careful With Your Gradle Repository Declarations

Gradle has a sophisticated process for downloading, caching, and managing third-party dependencies. However Gradle first needs to find where these dependencies are hosted. It will try to resolve each dependency by checking repositories one-at-a-time in the order they are listed in build.gradle files. Out of the box, a new Android Studio project will add two Gradle repositories to the project:

allprojects {
    repositories {
        google()
        jcenter()
    }
}

For each dependency, Gradle will first check Google’s repository for a matching dependency. If a match is found, it will then move on to the next dependency. If not, Gradle will then check JCenter’s repository. This linear search is very inefficient and creates potential security issues during the build process.

The security flaws are well documented in other stories. Simply put, if a malicious person puts a compromised “fake” artifact on a repository that is listed before a repository containing the “real” artifact, then Gradle will use that fake artifact; this situation can be hard to detect if you’re not explicitly looking for it.

I want to focus on the second issue: the inefficiencies caused by Gradle checking repositories that do not have the requested artifact.

Continue reading “Be Careful With Your Gradle Repository Declarations”

Understanding Different Gradle Caches for Android Projects, part 1.

There are several ways Gradle stores information between builds to drastically reduce subsequent build times. You may be familiar with some of these methods, but what’s important is that they build upon each other gradually improving build speed. If you are only benefiting from one, then you have something to gain by also looking into the others.

Continue reading “Understanding Different Gradle Caches for Android Projects, part 1.”