Plugins

Every Android project I've ever opened starts the same way. Right at the top of build.gradle, before any dependencies, before any SDK versions, before anything useful — there's this:

plugins {
    id("com.android.application")
    kotlin("android")
}

I copy-pasted those two lines into every project I created for months. I never touched them. I didn't know what they did. I was honestly scared that if I looked at them too hard something would break.

And then one day I created a new project and only saw one of them:

plugins {
    id("com.android.application")
}

The kotlin("android") line was gone. Just... missing. I panicked. Googled it. Added it back. The build failed. Removed it. The build worked again.

That was the moment I realized I had absolutely no idea what a Gradle plugin even was.

If you're in the same spot — let's fix that right now.

So What Is a Gradle Plugin, Actually?

Here's the simplest mental model I could come up with:

Gradle, on its own, knows how to do general build stuff. Compile files. Run tasks. Manage dependencies. It's a general-purpose build tool.

But Gradle has no idea what an Android app is. It doesn't know what an APK is. It doesn't know about AndroidManifest, or resources, or how to sign an app for the Play Store. Out of the box, it just doesn't speak Android.

A plugin is what teaches Gradle a new language.

When you apply com.android.application, you're saying: "hey Gradle, load the Android plugin — the one that knows how to build Android apps." Suddenly Gradle understands android { } blocks, knows how to produce an APK, understands build variants, knows what a manifest is.

Without the plugin, the android { } block in your Gradle file would be gibberish. Gradle would throw an error because it has no idea what that block means.

Think of it like this: Gradle is a blank canvas. Plugins are the brushes. You can't paint without picking up a brush first.

The Two Plugins Every Android App Uses (Or Used To)

com.android.application — The Android Brush

id("com.android.application")

This is the core Android plugin. It's what makes your module an app rather than just a bunch of Kotlin files. It adds:

• The ability to produce an APK or App Bundle
• The android { } configuration block
• Build types (debug / release)
• Support for Android resources, manifest merging, signing
• Every Android-specific Gradle task you've ever seen in the Build menu

This one is non-negotiable. Every Android app module has it. Without it, Gradle doesn't know it's building an Android app at all.

There's also a close cousin: com.android.library. Same idea, but for modules that produce a .aar library instead of an installable app. If you ever split your project into multiple modules, you'll meet it.

kotlin("android") — The Kotlin Brush (That You Might Not Need Anymore)

kotlin("android")
// this is shorthand for:
id("org.jetbrains.kotlin.android")

This one used to teach Gradle how to compile Kotlin code for Android. Without it, Gradle only understood Java. Add it, and suddenly .kt files become valid source code it knows how to build.

Here's the twist — and why I panicked when I saw it missing:

As of Android Gradle Plugin 9.0 (released January 2026), Kotlin support is now built directly into AGP itself. You no longer need to apply kotlin("android") separately. AGP already speaks Kotlin fluently.

So if you're starting a new project today on AGP 9.1.1 (the current latest), your plugins block looks like this:

plugins {
    id("com.android.application")
    // that's it. kotlin support is already included.
}

That's not a mistake. That's not a missing line. That's just how it works now.

But — and this is important — if you open an older project or follow an older tutorial, you'll still see kotlin("android") there. It still works. AGP 9.x accepts it for backwards compatibility. It just isn't required anymore.

Before vs After: What This Actually Looks Like

❌ The old way — AGP 8.x and older tutorials

// build.gradle.kts (Project level)
plugins {
    id("com.android.application") version "8.2.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

// build.gradle.kts (Module: app)
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android") // you had to add this yourself
}

android {
    compileSdk = 34
    ...
    kotlinOptions {
        jvmTarget = "11"
    }
}

Two plugins. Two separate version declarations at the project level. Both needed.

✅ The new way — AGP 9.x (2026)

// build.gradle.kts (Project level)
plugins {
    id("com.android.application") version "9.1.1" apply false
    // no kotlin plugin needed here anymore
}

// build.gradle.kts (Module: app)
plugins {
    id("com.android.application") // kotlin support is built in
}

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }

    // kotlinOptions block is also optional now in AGP 9.x
}

dependencies {
    val composeBom = platform("androidx.compose:compose-bom:2026.03.00")
    implementation(composeBom)
    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.material3:material3")
    implementation("androidx.activity:activity-compose:1.10.1")
    implementation("androidx.core:core-ktx:1.16.0")
}

Cleaner. Fewer moving parts. Less to break.

The Part Nobody Explains: apply false

You've probably noticed this in the project-level build.gradle and wondered what it means:

// Project-level
plugins {
    id("com.android.application") version "9.1.1" apply false
}

That apply false looks backwards. Why declare a plugin and then say "don't apply it"?

Here's the reason: the project-level file is a declaration hub, not an activation point. It's saying: "this plugin exists at version 9.1.1 — I'm registering it for the whole project." But it's not turning it on yet.

The actual activation happens in the module-level file:

// Module: app
plugins {
    id("com.android.application") // no version here 
}

This way, every module in your project that needs the plugin pulls the same version — the one declared at the top. No version drift. No conflicts. One source of truth.

The flow is:

• Project-level → "Here are the available plugins and their versions"
• Module-level → "I want to activate this one"

The Question That Unlocks Everything

Whenever you see a plugin you don't recognize, ask one question:

What does this teach Gradle to do?

com.android.application → teaches Gradle to build an Android app com.android.library → teaches Gradle to build an Android library module kotlin("android") → used to teach Gradle to compile Kotlin (now built into AGP) com.google.devtools.ksp → teaches Gradle to run KSP (Kotlin Symbol Processing) for annotation processing com.google.dagger.hilt.android → teaches Gradle about Hilt's code generation

Every plugin has a job. It extends what Gradle can do. Once you ask that one question about any plugin you encounter, it stops being magic and starts being a tool.

Closing Thought

Plugins are just extensions. They're not magic, they're not scary, and they're not lines you paste in and pretend don't exist.

com.android.application is the single most important line in your entire project. Without it, Gradle doesn't know it's building an Android app. Everything else in your build.gradle — the SDK versions, the dependencies, the build types — only makes sense because that plugin was applied first.

Now when you see that plugins { } block at the top of a file, you won't just scroll past it. You'll know exactly what each line is doing there.