skip to content

Ecosystem Plugins Overview

4 roadmaps31 questions

Orientation on the major third-party plugins — Android, Kotlin, Spring Boot, Jib — and which of their concepts belong to the plugin rather than to Gradle. Interviewers ask because candidates routinely attribute plugin behavior to Gradle itself.

on this pageshow

explore

questions

page 1 of 2

What is the android { } DSL block, and what is its role once AGP is applied?

level: juniorimportance: must knowfreq 60%

answer

  1. android = a Gradle extension AGP registers
  2. compileSdk, namespace, defaultConfig
  3. configures AGP's tasks, not Gradle's
  4. read during configuration phase
  5. absent without AGP applied

basics

~20 s

android { } 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 s

When 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 lines
kotlin
android {
    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

for a junior

Identify android { } as where you configure the Android build (compileSdk, namespace, defaultConfig) and that AGP provides it.

for a middle

Explain it is a Gradle extension AGP registers, list its main members, and that it is read during configuration to parameterize AGP tasks.

for a senior

Tie it to the extension mechanism (extensions.create) and the Provider/Property lazy model, and discuss application vs library extension type differences.

for a principal

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.

context

resolving links…

open as a page

What is the Android Gradle Plugin (AGP), and how does it relate to Gradle itself?

level: juniorimportance: must knowfreq 70%

basics

~20 s

AGP is a Gradle plugin you apply with com.android.application (or com.android.library). Gradle is the generic build engine; AGP teaches Gradle how to build an Android app — compile, package an APK/AAB, and run Android-specific tasks.

open as a page

What are build types in the Android Gradle Plugin (AGP), and what do the default `debug` and `release` build types represent?

level: juniorimportance: must knowfreq 70%

basics

~10 s

Build types are AGP configurations for how an app is built. AGP ships two by default: debug (debuggable, no shrinking) and release (optimizable, shrinkable, signable for distribution).

open as a page

What is the Jib Gradle plugin and how does it build a container image differently from a typical Dockerfile-based build?

level: juniorimportance: must knowfreq 55%

basics

~10 s

Jib is a Gradle plugin (com.google.cloud.tools.jib) that builds an OCI/Docker image for a JVM app directly from your build, with no Dockerfile and no Docker daemon. You run a task like jib or jibDockerBuild.

open as a page

What is the Kotlin Multiplatform Gradle plugin, and how do you declare the platforms a module should compile for?

level: juniorimportance: must knowfreq 60%

basics

~10 s

Apply the org.jetbrains.kotlin.multiplatform plugin, then open a kotlin { } block and call target functions like jvm(), js(), and iosX64(). Each call adds a platform the module compiles for.

open as a page

How do you apply the Kotlin Gradle Plugin for a JVM project, and what does applying org.jetbrains.kotlin.jvm actually add to your build?

level: juniorimportance: must knowfreq 70%

basics

~10 s

Add id("org.jetbrains.kotlin.jvm") version "…" in the plugins {} block. It registers Kotlin source sets, a kotlin {} extension, and compileKotlin tasks that compile .kt files into JVM bytecode.

open as a page

What does the Spring Boot Gradle plugin do, and what is the difference between bootJar and the standard jar task?

level: juniorimportance: must knowfreq 78%

basics

~10 s

Applying org.springframework.boot adds a bootJar task that builds an executable 'fat jar' bundling your code plus all dependencies and a launcher. The plain jar task only packages your own classes.

open as a page

How does AGP add an Android build pipeline on top of Gradle's lifecycle phases?

level: middleimportance: must knowfreq 55%

basics

~10 s

Gradle runs init → configuration → execution. During configuration, AGP registers its tasks (manifest merge, resource processing, compile, dex, package) and wires their inputs/outputs. During execution Gradle runs that graph to produce the APK/AAB.

open as a page

What are product flavors in AGP, and how do flavor dimensions let you combine them?

level: middleimportance: must knowfreq 60%

basics

~10 s

Product flavors define what version of an app you build (e.g. free vs paid). Flavor dimensions group flavors so AGP combines one flavor from each dimension into the final app.

open as a page

How does AGP compute the build variant matrix from build types and product flavors, and what tasks/source sets does each variant produce?

level: middleimportance: must knowfreq 55%

basics

~20 s

A variant is one combination: (one flavor per dimension) × (one build type). AGP multiplies them — e.g. 2 flavors × 2 build types = 4 variants — and generates a source set and assemble<Variant> task for each.

open as a page

Walk through the jib { from, to, container } DSL: what does each block configure and what are the key fields?

level: middleimportance: must knowfreq 48%

basics

~10 s

from sets the base image. to sets the target image name/tags and auth. container configures runtime: jvmFlags, mainClass, ports, entrypoint, environment, labels.

open as a page

Explain the difference between the jib, jibDockerBuild, and jibBuildTar tasks and when you would use each.

level: middleimportance: must knowfreq 50%

basics

~10 s

jib pushes the image to a registry. jibDockerBuild loads it into the local Docker daemon. jibBuildTar writes the image to a tarball file. Choose by destination.

open as a page

How do you set the JVM target bytecode level with the Kotlin Gradle Plugin, and how does compilerOptions { jvmTarget } relate to the kotlin { jvmToolchain(...) } setting?

level: middleimportance: must knowfreq 65%

basics

~10 s

Set the bytecode level via kotlin { compilerOptions { jvmTarget.set(JvmTarget.JVM_17) } }. Use kotlin { jvmToolchain(17) } to also choose which JDK compiles and runs the code; the toolchain conveniently aligns the jvmTarget too.

open as a page

How does io.spring.dependency-management relate to the Spring Boot plugin, and how does BOM-aligned version management work in a Gradle build?

level: middleimportance: must knowfreq 70%

basics

~10 s

The Spring Boot plugin imports the Boot BOM so you can declare dependencies without versions, and Gradle resolves consistent, tested versions for you. Versionless starters 'just work' because the BOM pins them.

open as a page

What is the kotlin {} extension that KGP adds, and what do you typically configure in it for a JVM project?

level: juniorimportance: should knowfreq 50%

basics

~10 s

It's the project extension KGP registers as the single entry point for Kotlin configuration. In a JVM module you commonly set jvmToolchain(...) and compilerOptions { … } (jvmTarget, languageVersion, freeCompilerArgs).

open as a page

Given a fresh Gradle build, show how you'd apply the Spring Boot plugin and explain why applying it alone doesn't pull in Spring dependencies.

level: juniorimportance: should knowfreq 55%

basics

~10 s

Add id("org.springframework.boot") in the plugins block. That only wires up tasks like bootJar/bootRun and the BOM; you still declare starters such as spring-boot-starter-web yourself to get actual Spring code.

open as a page

How are AGP, Gradle, and the JDK versions related, and how do you manage upgrades?

level: middleimportance: should knowfreq 45%

basics

~10 s

AGP and Gradle version independently but each AGP requires a minimum Gradle and JDK. You set AGP in the plugins/version catalog and Gradle in gradle-wrapper.properties. Use Google's compatibility matrix and upgrade them together.

open as a page

Explain the source-set hierarchy in a Kotlin Multiplatform module and how an intermediate source set like `iosMain` fits in.

level: middleimportance: should knowfreq 45%

basics

~20 s

Source sets form a tree: commonMain is the root, and each platform source set dependsOn it. Intermediate sets like iosMain group several related native targets (iosArm64, iosSimulatorArm64) so they can share code above common but below the individual targets.

open as a page

When you declare multiple targets in a KMP module, what tasks does the plugin generate and how do you build or test a single platform?

level: middleimportance: should knowfreq 40%

basics

~10 s

Each target gets its own tasks — e.g. compileKotlinJvm, jvmJar, jvmTest, compileKotlinIosArm64, iosX64Test. To build or test just one platform you run the target-prefixed task, like ./gradlew jvmTest instead of ./gradlew check.

open as a page

Where does the Kotlin Gradle Plugin add Kotlin compilation into the Gradle build, and what kind of task is compileKotlin?

level: middleimportance: should knowfreq 40%

basics

~10 s

KGP registers a KotlinCompile task named compileKotlin per source set (plus compileTestKotlin), wired into the classes lifecycle. It's an incremental, cacheable task whose output joins the same classpath as Java compilation.

open as a page

What do compilerOptions { languageVersion } and apiVersion mean in the Kotlin Gradle Plugin, and when would you set them?

level: middleimportance: should knowfreq 45%

basics

~20 s

languageVersion tells the Kotlin compiler which version of the Kotlin language/syntax to accept; apiVersion restricts which stdlib/runtime API you may use to that version. You set them to compile in a compatibility mode older than the compiler you're running.

open as a page

What is the bootRun task, and how do you pass arguments, JVM options, system properties, or an active profile to it?

level: middleimportance: should knowfreq 60%

basics

~10 s

bootRun launches your Spring Boot app from the build using the main source set's runtime classpath, without building a jar first. You configure it to pass program args, JVM flags, and system properties.

open as a page

Why can't a plain Gradle java/kotlin build produce an Android APK, and what exactly does AGP supply that Gradle lacks?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Plain Gradle plugins only compile JVM bytecode and jar it. Android needs manifest merging, resource/AAPT2 processing, R-class generation, dexing to DEX, and APK/AAB packaging and signing — none of which Gradle's JVM plugins know how to do. AGP adds all of that.

open as a page

A team's AGP build has grown to dozens of variants and CI is slow. How do you reason about and control the variant explosion?

level: seniorimportance: should knowfreq 30%

basics

~10 s

Variants multiply (flavors-per-dimension × build types), so they explode fast. Prune impossible combinations with beforeVariants/variantFilter, reduce dimensions, and have CI build only the variants it actually needs.

open as a page

How do AGP build types, flavors, and variants relate to Gradle core concepts like source sets, configurations, and tasks?

level: seniorimportance: should knowfreq 40%

basics

~10 s

Build types, flavors, and variants are AGP-only abstractions. AGP implements them by generating Gradle source sets, dependency configurations (like <variant>Implementation), and tasks (assemble<Variant>) — Gradle core itself has no variant concept.

open as a page

How does Jib's layering strategy interact with build caching to make incremental container builds fast?

level: seniorimportance: should knowfreq 38%

basics

~10 s

Jib splits the app into separate layers — dependencies, snapshots, resources, classes. Unchanged layers keep the same digest and are pulled from cache, so only the changed classes layer is rebuilt and pushed.

open as a page

How do you configure Jib for a Spring Boot application, and what should you watch out for compared to a plain JVM app?

level: seniorimportance: should knowfreq 34%

basics

~10 s

Apply Jib alongside the Spring Boot plugin, point container.mainClass at your @SpringBootApplication class, expose the server port, and set jvmFlags. Jib containerizes the exploded app, not the repackaged fat JAR.

open as a page

How is a Kotlin Multiplatform library published and consumed, and what role does Gradle variant-aware resolution play?

level: seniorimportance: should knowfreq 30%

basics

~20 s

A KMP library publishes a root metadata module plus one Gradle module per target (jvm, iosArm64, js…), each with attributes. When a consumer adds the library, Gradle's variant-aware resolution matches each target's attributes to pick the correct per-platform artifact automatically.

open as a page

How does the Spring Boot plugin's task design (lazy registration, inputs/outputs, config-cache compatibility) affect build performance and correctness, and what pitfalls have you hit configuring bootJar/bootRun?

level: seniorimportance: should knowfreq 35%

basics

~10 s

The plugin registers bootJar/bootRun lazily and declares proper task inputs/outputs so they're incremental and cacheable. Misconfiguring them — e.g. eager resolution or non-cacheable inputs — breaks up-to-date checks and the configuration cache.

open as a page

How does Jib authenticate to registries, and how do you produce a multi-architecture image?

level: seniorimportance: nice to knowfreq 26%

basics

~10 s

Jib reads credentials from Docker config, credential helpers, or explicit from/to auth blocks. For multi-arch you list platforms under from { platforms { ... } } and Jib pushes a manifest list.

open as a page

showing 1–30 of 31