What is the difference between project-level and module-level build.gradle?
Gradle scope in multi-module Android projects.
Project level sets plugin repos and shared versions; module level sets dependencies, build types, and flavors.
Claiming both files do the same thing or misplacing plugins.
What's really being asked
This question checks whether you understand the hierarchical nature of Gradle builds in Android and can distinguish between global project configuration and local module configuration. A senior candidate should demonstrate awareness of separation of concerns, know where to apply plugins, and understand that modern Android projects are almost always multi-module. The interviewer wants to see that you have debugged build issues by knowing which file to edit.
The full answer
A strong answer explains that the project-level build.gradle acts as the global configuration for the entire Gradle build. It typically lives in the root project directory and defines plugin repositories in the plugins block or dependency resolution management, sets up shared version catalogs, and may declare classpath dependencies for Gradle plugins themselves. In contrast, the module-level build.gradle lives inside each module folder such as app or library modules and applies the Android-specific plugins like com.android.application or com.android.library. It declares the module's own dependencies, configures the android block with compileSdk, defaultConfig containing applicationId and minSdk, and defines build types like debug and release, product flavors, signing configurations, and packaging options. A great candidate also notes that a single project has exactly one project-level file but can have many module-level files, and that the module file can reference ext variables or version catalogs defined at the project level.
The mistakes people make
Red flags include saying both files are identical in purpose, claiming that dependencies always go in the project-level file, or stating that the Android application plugin belongs in the project-level build.gradle. Another weak signal is describing only the app module and forgetting that library modules also have their own module-level build.gradle files. Confusing the old classpath dependencies in buildscript blocks with modern plugins DSL also suggests outdated knowledge.
What usually comes next
An interviewer may ask where you should define a dependency version that multiple modules share, how version catalogs change this workflow, or what happens when you apply a plugin at the project level versus the module level. They might also ask how buildSrc or convention plugins reduce duplication across many module-level files, or how to configure a custom Gradle plugin in the project-level file.
A concrete example
Imagine a project with an app module and two library modules. The project-level build.gradle sets pluginManagement repositories to google() and mavenCentral(), and defines an ext.kotlin_version variable. Each module-level build.gradle applies plugins such as com.android.application for the app and com.android.library for the libraries, sets compileSdk to 34, and adds unique dependencies like Retrofit for the app module and JUnit for a library test suite. The app module also defines buildTypes with minification enabled in release, while the library modules do not.
Interview question
In a multi-module Android project, which configuration belongs in the project-level build.gradle rather than a module-level file?
- a.compileSdk, minSdk, and debug/release build types
- b.The com.android.application plugin and the module's third-party dependencies
- c.Product flavors and signing configurations for release builds
- d.Plugin repository declarations such as google() and mavenCentral()Correct
Why? this is the answer
The project-level build.gradle manages global build infrastructure like plugin repositories and shared versions, while module-level files handle Android plugins, dependencies, and build types. Option B is a common misconception because the com.android.application plugin must be applied in the app module's build.gradle, not the project-level file.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #gradle
- #build-system
- #multi-module
- #interview
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles