What is the android { } DSL block, and what is its role once AGP is applied?
answer
- android = a Gradle extension AGP registers
- compileSdk, namespace, defaultConfig
- configures AGP's tasks, not Gradle's
- read during configuration phase
- absent without AGP applied
basics
~20 sandroid { } is the configuration extension AGP registers when you apply it. Inside it you set things like compileSdk, namespace, and defaultConfig. It configures AGP's tasks; without AGP applied, the block does not exist.
solid answer
~40 sWhen you apply AGP, it registers a Gradle **extension** named `android`, so the `android { }` block becomes available in that module's build script. This block is the central place to configure the Android build: `compileSdk` (the API level you compile against), `namespace` (the package for the generated R class), `defaultConfig` (applicationId, minSdk, targetSdk, versionCode/versionName), `buildTypes` (debug/release), signing configs, and feature toggles like `buildFeatures`. Mechanically it is just a typed Gradle extension object — the same mechanism any plugin uses via `project.extensions.create(...)`. The values you set are read during the configuration phase and feed AGP's registered tasks. Importantly, the block is purely AGP's: a vanilla Gradle build has no `android` extension, which underscores that all Android configuration surface is contributed by the plugin, not by Gradle.
code
kotlin · 12 linesandroid {
namespace = "com.example.app"
compileSdk = 34
defaultConfig {
applicationId = "com.example.app"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
buildFeatures { viewBinding = true }
}go deeper
Identify android { } as where you configure the Android build (compileSdk, namespace, defaultConfig) and that AGP provides it.
Explain it is a Gradle extension AGP registers, list its main members, and that it is read during configuration to parameterize AGP tasks.
Tie it to the extension mechanism (extensions.create) and the Provider/Property lazy model, and discuss application vs library extension type differences.
Discuss centralizing android { } conventions across modules via convention plugins to avoid per-module drift in a large codebase.
## What an extension is Gradle lets a plugin contribute configuration surface through an **extension** — a typed object registered on the `Project` via `project.extensions.create("name", Type::class.java)`. The script then configures it with a block of the same name. AGP registers an extension called `android`, which is why, *only after applying AGP*, your build script can write `android { ... }`. ## What lives inside android { } The block is the single configuration hub for the Android build. Common members: - `compileSdk` — the SDK/API level the code is compiled against. - `namespace` — the package name used to generate the `R` class and `BuildConfig` (replaces the old manifest `package` attribute). - `defaultConfig { }` — `applicationId`, `minSdk`, `targetSdk`, `versionCode`, `versionName`, test runner, etc. - `buildTypes { }` — `debug` and `release` defaults; toggles like `isMinifyEnabled` and ProGuard/R8 files. - `signingConfigs { }` — keystore/key references used to sign outputs. - `buildFeatures { }` — switches such as `buildConfig`, `viewBinding`, `compose`. - `compileOptions { }` / `kotlinOptions` (older AGP) — Java/Kotlin language and bytecode targets. ```kotlin android { namespace = "com.example.app" compileSdk = 34 defaultConfig { minSdk = 24 targetSdk = 34 } buildTypes { release { isMinifyEnabled = true } } buildFeatures { buildConfig = true } } ``` ## When the block is read The `android { }` block executes during Gradle's **configuration phase**. The values populate AGP's extension object; AGP's registered tasks then read those properties (often lazily through Gradle's `Provider`/`Property` API) when they configure and execute. So configuring `android` does not *do* the build — it parameterizes the tasks AGP will run during execution. ## Why it matters that it is AGP's The block is the clearest marker of the Gradle/AGP boundary: it does not exist in a plain JVM build. Every key inside it is Android domain knowledge supplied by the plugin. The `application` and `library` variants of AGP expose slightly different android extension types (e.g. `applicationId` exists only for the application plugin), reflecting their different outputs.
- What is the difference between compileSdk, minSdk, and targetSdk?compileSdk is the API level you compile against (which APIs are visible). minSdk is the lowest OS version the app installs on. targetSdk is the API level the app declares it was tested against, affecting runtime behavior/compat shims.
- Why did namespace move into android { } instead of the manifest?Modern AGP took the package/namespace out of AndroidManifest.xml and into the android { } namespace property to decouple the R/BuildConfig package from the manifest and reduce manifest merging surprises.
saying these in an interview costs you the question
- Calling android { } a Gradle built-in — it is an AGP-registered extension.
- Confusing compileSdk with targetSdk — they serve different purposes.