Project-level vs. module-level build.gradle files

What's really being asked

This is a fundamental question checking your understanding of Gradle's hierarchical structure in an Android project. The interviewer wants to see if you know how configuration is scoped—what applies globally versus what is specific to a single library or application module. For senior candidates, it's also a test of whether your knowledge is current, specifically regarding the shift from build.gradle to settings.gradle for plugin and repository management.

The full answer

A strong answer explains the roles sequentially. First, the project-level (root) build.gradle file configures settings for all modules in the project. This traditionally includes defining repositories (like google() and mavenCentral()) and classpath dependencies for build tools like the Android Gradle Plugin (AGP). Second, the module-level build.gradle file (e.g., app/build.gradle) configures settings for that specific module only. This includes applying plugins (com.android.application), setting the minSdk and targetSdk, defining the applicationId, and most importantly, declaring the module's dependencies. A great answer will also note that modern best practice moves repository and plugin management from the root build.gradle into settings.gradle(.kts).

The mistakes people make

A major red flag is confusing the roles, for example, suggesting you'd declare an app dependency like Retrofit in the project-level file or place repository definitions in a module-level file. Another weak signal is describing the system without mentioning the modern evolution. A senior candidate who only describes the old buildscript block in the root build.gradle without mentioning the plugins block in settings.gradle or version catalogs (libs.versions.toml) appears to have outdated knowledge.

What usually comes next

"How would you share a dependency version across multiple modules?", which leads to talking about ext properties (older way) or a version catalog (modern way). Another is, "What is the purpose of the settings.gradle file?"

A concrete example

The project-level build.gradle (or now, settings.gradle) might specify AGP version 8.4.0 for the entire project. Each module, however, will have its own build.gradle file. The app module's file will have apply plugin: 'com.android.application', while a networking library module's file will have apply plugin: 'com.android.library'. The app module will depend on the networking module via implementation project(':networking') in its own build.gradle.