How do you control where Gradle gets your Android dependencies?

Declare repositories once in settings.gradle.kts and set the repositories mode to fail the build if a project or module adds its own. That gives you one reviewed list of places your Android app can download code from, instead of one list per module that anyone can change.

What Gradle offers

Gradle's documentation on centralizing repositories describes three modes for the repositoriesMode setting:

• PREFER_PROJECT, the default: repositories declared in a project override those in settings.
• PREFER_SETTINGS: repositories in settings take precedence, and Gradle warns when a project or plugin declares one.
• FAIL_ON_PROJECT_REPOS: declaring a repository in a project fails the build.

A settings file that uses the strict mode looks like this:

// settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        mavenCentral()
        google()
    }
    repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
}

The Gradle page shows the first form with PREFER_SETTINGS. The strict mode is one of the three it lists. Test it on your Gradle version.

Why it matters

Every repository you list is a place a build trusts to supply code. An extra repository added in one module, perhaps for a single library, becomes a place that can supply any library with a matching name. That is the setup for dependency confusion, where a public package takes the place of an internal one.

Central control also helps review. A change to the repository list is a change to the settings file, which people can review once, not a line buried in a module.

Steps

1. List every repository your project and plugins declare today.
2. Move the needed ones into the settings file.
3. Switch the mode to fail on project repositories.
4. Fix the modules that break by removing their private repository declarations.
5. For an internal repository, document the owner and who can publish to it.
6. Put changes to the settings file under code review.

What goes wrong without it

Android projects often have many modules and several plugins, each able to declare repositories. Over time a build collects repositories nobody remembers adding: a mirror used for one old library, a snapshot repository from a prototype, a vendor repository whose credentials left with the person who set it up. A new engineer reading the root build file sees one list and assumes it is the whole story.

Making the settings file the single source also shortens incident response. When someone asks where a given library could have come from, you read one file.

Pair it with other controls

Locking and verification are covered in Gradle dependency locking and Gradle dependency verification.

Quick check

Safeguard works on the next layer, scanning the resolved dependencies and SBOM for known vulnerabilities and enforcing policy gates. A free scan is available.

Sources

• Gradle: centralizing repository declarations

Last reviewed: 19 October 2026.