Kotlin DSL's Strongly-Typed Design and Engineering Migration Practices

The Kotlin DSL is not merely a "syntax skin" slapped over the Groovy DSL; it is a compilation mechanism engineered by Gradle to re-expose the dynamic build model to a static type system.

The previous article dissected the Groovy DSL: build.gradle is compiled into a Groovy script class, where unqualified methods, properties, and closure delegates trace a dynamic lookup path through Script, Binding, Project, and extension containers. Its advantage is permissiveness—any name injected into the namespace at runtime by a plugin can be resolved on the fly. Its catastrophic cost is late error discovery, weak IDE inference, and blurred refactoring boundaries.

The Kotlin DSL adopts a radically different paradigm: the script configures the exact same Gradle model, but before compiling the script, Gradle attempts to organize dynamic models—like Project, Settings, plugin extensions, dependency configurations, and task containers—into types comprehensible to the Kotlin compiler. Thus, android {}, implementation(...), and tasks.test {} are no longer resolved via "runtime guessing"; they are materialized into concrete Kotlin functions, properties, and extension functions.

Imagine the two DSLs as different control rooms:

• The Groovy DSL is a voice-activated control room. The operator shouts, "Open the implementation channel!" The system waits until runtime to check if that channel actually exists.
• The Kotlin DSL is a hardwired control panel. Only buttons that have been structurally wired into the schematics appear on the panel. Pressing a non-existent button is flagged as a failure before the system powers on.

This is the core engineering yield of the Kotlin DSL, and paradoxically, the root cause of the most agonizing migration pitfalls: It is not a "more verbose" version of Gradle. It forcefully shifts runtime script failures forward into the compilation phase.

From Script File to Kotlin Program

Gradle Kotlin DSL scripts bear the .gradle.kts extension. The kts stands not for "configuration file," but for Kotlin Script. The official documentation explicitly states: like the Groovy DSL, the Kotlin DSL is built atop the Gradle Java API. The objects, functions, and properties within the script originate primarily from the Gradle API and the APIs of applied plugins.

Therefore, an Android module script:

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

android {
    namespace = "club.zerobug.app"
    compileSdk = 36
}

dependencies {
    implementation("androidx.core:core-ktx:1.17.0")
}

Underneath, it is still configuring the :app Project:

build.gradle.kts
   |
   | 1. Parse early blocks like plugins{}
   v
Plugin requests + script classpath
   |
   | 2. Apply plugins, locking down the visible model
   v
Project + extensions + configurations + tasks
   |
   | 3. Generate Kotlin DSL Type-Safe Accessors
   v
accessors classpath
   |
   | 4. Compile the script body
   v
Kotlin Bytecode
   |
   | 5. Execute script, configuring the Gradle model
   v
Project model configuration complete

The critical phases here are Step 2 and Step 3: Gradle must know what models the plugins provide before it can generate accessors like android {} or implementation(...). In other words, the type safety of the Kotlin DSL is not a result of the Kotlin compiler possessing innate knowledge of the Gradle universe. Instead, before compiling the script, Gradle scans the model, generates a batch of Kotlin code on the fly, and injects that generated code into the script's compilation classpath.

Gradle's source code, specifically StandardKotlinScriptEvaluator, maps this exact trajectory: it prepares the compilation classpath, plugin block accessors, and project model accessors, subsequently caching the compilation artifacts. ProjectAccessorsClassPathGenerator further reveals the inputs for accessor generation: the target script object, project schema, script classpath, execution engine, and cache workspace.

Condensed into pseudocode:

val pluginRequests = parsePluginsBlock(script)
applyPluginsTo(project, pluginRequests)

val schema = projectSchemaProvider.schemaFor(project, lockedClassLoaderScope)
val accessorsClasspath = generateProjectAccessors(schema, scriptClasspath)

compileKotlinScript(
    source = buildGradleKts,
    classpath = gradleApi + pluginClasspath + accessorsClasspath,
)

This uncovers a profound truth: The Kotlin DSL's type safety is "build-time generated type safety." It is neither completely static (detached from Gradle) nor completely dynamic (relying on Groovy's runtime fallbacks). It stands precisely in the middle: Gradle constructs a snapshot of the model visible to the current script, and the Kotlin compiler then audits the script against that snapshot.

Type-Safe Accessors: Turning Dynamic Models into Completable Code

In Groovy DSL, you can write:

dependencies {
    implementation 'androidx.core:core-ktx:1.17.0'
}

The name implementation is rarely a method physically declared on DependencyHandler. It is typically a dependency configuration instantiated by the Java, Android, or Kotlin plugin. The dynamic Groovy DSL intercepts "configuration name + arguments" and translates it to "add a dependency to this configuration."

Kotlin cannot play this game. When compiling the script, the Kotlin compiler must strictly know what implementation is, otherwise it terminates with:

Unresolved reference: implementation

Gradle's solution is generating Type-Safe Accessors. Conceptually, it synthesizes Kotlin extensions for models contributed by plugins, looking something like this:

// Conceptual illustration: The actual generated code is more complex.
fun DependencyHandler.implementation(dependencyNotation: Any): Dependency? {
    return add("implementation", dependencyNotation)
}

val Project.android: CommonExtension<*, *, *, *, *, *>
    get() = extensions.getByName("android") as CommonExtension<*, *, *, *, *, *>

fun Project.android(configure: CommonExtension<*, *, *, *, *, *>.() -> Unit) {
    extensions.configure("android", configure)
}

Because of this, the script content:

android {
    namespace = "club.zerobug.app"
}

dependencies {
    implementation("androidx.core:core-ktx:1.17.0")
}

...can be validated by the Kotlin compiler just like standard Kotlin code. If namespace is misspelled, if implementation doesn't exist, or if the argument type is blatantly wrong, it explodes during script compilation.

This mechanism enforces very specific boundaries.

Only Models After the Plugins Block Receive Stable Accessors

The official Gradle documentation specifies that main project build scripts and precompiled project script plugins possess type-safe model accessors. These cover dependency configurations, extensions, tasks, and container elements contributed by plugins. However, the available set of accessors is finalized before the script body executes, specifically after the plugins {} block.

Therefore, this works perfectly:

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

android {
    namespace = "club.zerobug.app"
}

But this syntax cannot expect generated accessors:

plugins {
    id("java")
}

configurations.create("benchmarkRuntime")

dependencies {
    // benchmarkRuntime is created DURING script execution.
    // Kotlin DSL will NOT pre-generate a type-safe accessor for it.
    "benchmarkRuntime"("androidx.benchmark:benchmark-junit4:1.4.1")
}

Here, you must retreat to the string-based API:

dependencies {
    add("benchmarkRuntime", "androidx.benchmark:benchmark-junit4:1.4.1")
}

The underlying reason is brutally simple: Accessor generation occurs before the script body runs. configurations.create("benchmarkRuntime") is a side effect triggered while the script body runs. The compiler cannot reference a name that will be created by the script in the future.

apply(plugin = ...) Weakens Accessor Capabilities

Gradle still supports imperative plugin application:

apply(plugin = "com.android.application")

android {
    namespace = "club.zerobug.app"
}

However, this pattern is catastrophic as a primary migration path. It isn't just "ugly"; it shatters the foundational prerequisite of the Kotlin DSL: Gradle needs to know which models plugins contribute before compiling the script body.

plugins {} is an early declaration. Gradle parses it, applies the plugins, generates accessors, and then compiles the script body. apply(plugin = ...) is standard script code; it lives inside the script body. By the time it executes, the script has already been compiled, and the window for generating type-safe accessors has irrevocably slammed shut.

Thus, the first principle of Kotlin DSL migration is:

If a plugin can be placed in plugins{}, NEVER leave it in apply(plugin = ...).

For the rare plugins that cannot be resolved via plugin portal metadata, resolve them via pluginManagement, resolutionStrategy, includeBuild("build-logic"), or plugin aliases in the version catalog. Do not regress to fragmented buildscript {} and apply statements.

Kotlin DSL Script Templates: Why Top-Level android {} is Allowed

In standard Kotlin files, you cannot arbitrarily place repositories {}, dependencies {}, or tasks {} at the top level. They function in the Kotlin DSL because Gradle wires different script templates and implicit receivers to different script types.

The relationship between script files and backing objects looks like this:

In the Gradle source, script base classes like KotlinBuildScript and KotlinSettingsScript mount the script target objects into the KotlinScriptHost. Unqualified top-level calls resolve against the current script target, Gradle APIs, Kotlin DSL APIs, implicit imports, and generated accessors.

This looks similar to Groovy's dynamic delegation, but its nature is fundamentally different:

Groovy DSL:
  Name appears -> Dynamic lookup at runtime -> Throws error only if missing.

Kotlin DSL:
  Name appears -> Type resolution at compile time -> Halts compilation if missing.

For Android engineering, this distinction is monumental. Massive cohorts of build errors no longer wait in ambush until CI triggers a specific task; they are aggressively flagged during IDE sync or script compilation. For example:

android {
    compileSdk = "36"
}

This type error doesn't manifest as a confusing runtime exception; the Kotlin compiler immediately demands an Int or the appropriate property type.

Android Migration is Not Just Changing File Extensions

The official Android migration guide offers highly pragmatic first steps: add parentheses and assignment operators in your Groovy files before renaming them to Kotlin. This isn't superficial formatting; it's the systematic eradication of Groovy syntactic sugar.

Groovy:

android {
    namespace 'club.zerobug.app'
    compileSdk 36

    defaultConfig {
        minSdk 26
        targetSdk 36
        versionCode 1
        versionName '1.0'
    }
}

Kotlin:

android {
    namespace = "club.zerobug.app"
    compileSdk = 36

    defaultConfig {
        minSdk = 26
        targetSdk = 36
        versionCode = 1
        versionName = "1.0"
    }
}

This is merely the entryway. The true crucible of migration lies here: Groovy permits massive amounts of "figure it out at runtime" syntax, while the Kotlin DSL demands absolute clarity regarding object boundaries.

String Literals Must Become Explicit Invocations

Groovy dependency declaration:

dependencies {
    implementation 'androidx.core:core-ktx:1.17.0'
    testImplementation 'junit:junit:4.13.2'
}

Kotlin DSL:

dependencies {
    implementation("androidx.core:core-ktx:1.17.0")
    testImplementation("junit:junit:4.13.2")
}

This isn't just Kotlin being pedantic about parentheses. implementation(...) is now a concrete function invocation. The parentheses bind the action "add a dependency to the implementation configuration" to a function the compiler can statically verify.

Boolean Properties Frequently Shift from minifyEnabled to isMinifyEnabled

In Groovy, you simply write:

buildTypes {
    release {
        minifyEnabled true
        shrinkResources true
    }
}

The Kotlin DSL mandates adherence to Kotlin's JavaBean boolean property naming conventions:

buildTypes {
    release {
        isMinifyEnabled = true
        isShrinkResources = true
    }
}

isMinifyEnabled isn't the Android plugin abruptly changing concepts; it is the name Kotlin synthesizes when exposing Java's isMinifyEnabled() / setMinifyEnabled(Boolean) pair as a property. Relying solely on find-and-replace during migration often strands developers on these bean property mappings.

Container Elements Must Express Lifecycles via named, register, and creating

Legacy Groovy DSL pattern:

tasks.register('printVariant') {
    doLast {
        println 'variant'
    }
}

Kotlin DSL:

tasks.register("printVariant") {
    doLast {
        println("variant")
    }
}

Crucially, when configuring an existing task, resist the urge to use getByName:

tasks.named<Test>("test") {
    useJUnitPlatform()
}

tasks.named<T>() returns a TaskProvider<T>. This aligns directly with the Provider API and Task Configuration Avoidance design philosophies covered in the previous article: you are holding a "lazy reference to a future task," not eagerly forcing the task object into existence. The Gradle documentation explicitly confirms that Kotlin DSL task accessors leverage configuration avoidance APIs.

In other words, the Kotlin DSL doesn't just make scripts auto-completable; it structurally coerces your engineering practices toward lazier, vastly more cacheable configuration paradigms.

Version Catalogs: Turning String Dependencies into Governable Inputs

While Kotlin DSL's type-safe accessors solve typing for configuration names, extensions, and tasks, if dependency coordinates remain scattered as strings across every module, the project architecture remains fragile:

dependencies {
    implementation("androidx.core:core-ktx:1.17.0")
    implementation("androidx.activity:activity-compose:1.12.1")
}

Version Catalogs centralize dependency coordinates into gradle/libs.versions.toml:

[versions]
androidx-core = "1.17.0"
activity-compose = "1.12.1"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "androidx-core" }
androidx-activity-compose = { group = "androidx.activity", name = "activity-compose", version.ref = "activity-compose" }

[plugins]
android-application = { id = "com.android.application", version = "8.13.1" }
kotlin-android = { id = "org.jetbrains.kotlin.android", version = "2.2.21" }

Modules can then declare:

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
}

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.activity.compose)
}

The official docs emphasize that the Version Catalog generates type-safe accessors for the aliases defined in the TOML file. The IDE can autocomplete, spellcheck, and flag missing dependencies. However, remember the architectural boundary: The Version Catalog is not a dependency resolution engine. It merely declares coordinates and version requests. The final selected version is still dictated by Gradle's dependency resolution, constraints, platforms/BOMs, and conflict resolution rules.

Therefore, the Version Catalog excels at:

• Consolidating dependency coordinates and plugin versions to eliminate hardcoding in module scripts.
• Making dependency aliases auto-completable and refactorable in the Kotlin DSL.
• Operating alongside BOMs or Gradle platforms to manage version alignment (though it does not replace conflict resolution).
• Providing an auditable dependency manifest for multi-module projects.

Never treat the Version Catalog as a "global variable warehouse." It governs dependency coordinates; it should not govern business configurations, signing keys, build flags, or task logic.

Precompiled Script Plugins: The True Landing Zone for Multi-Module Migrations

When migrating a massive Android project to the Kotlin DSL, the most disastrous strategy is morphing every module into a monolithic build.gradle.kts file, endlessly replicating identical configurations for Android, Kotlin, Compose, testing, Lint, and publishing.

Repetitive configuration breeds three diseases:

1. A single rule change requires mutating dozens of modules.
2. Modules appear uniform initially, but details inevitably drift.
3. As scripts bloat, type safety remains only as a syntactic nicety, while architectural leverage vanishes.

Gradle's robust solution is Precompiled Script Plugins. These are essentially .gradle.kts files residing within buildSrc or an isolated build-logic included build. Gradle compiles them into legitimate plugin classes, deriving the plugin ID from the filename.

The directory architecture looks like this:

settings.gradle.kts
build-logic/
  build.gradle.kts
  src/main/kotlin/
    zerobug.android.application.gradle.kts
    zerobug.android.library.gradle.kts
    zerobug.android.compose.gradle.kts
app/
  build.gradle.kts
feature/feed/
  build.gradle.kts

build-logic/build.gradle.kts:

plugins {
    `kotlin-dsl`
}

repositories {
    google()
    mavenCentral()
    gradlePluginPortal()
}

dependencies {
    implementation("com.android.tools.build:gradle:<agp-version>")
    implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:<kotlin-version>")
}

If build-logic is an independent included build, it maintains its own settings and dependency resolution boundaries. You can explicitly import the main build's libs.versions.toml into build-logic/settings.gradle.kts, or maintain a dedicated catalog exclusively for build logic. Do not blindly assume the libs accessor from the main script automatically permeates into another distinct build.

build-logic/src/main/kotlin/zerobug.android.library.gradle.kts:

plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

android {
    compileSdk = 36

    defaultConfig {
        minSdk = 26
    }
}

The business modules are drastically thinned out:

plugins {
    id("zerobug.android.library")
}

android {
    namespace = "club.zerobug.feature.feed"
}

dependencies {
    implementation(projects.core.model)
    implementation(libs.androidx.core.ktx)
}

This is the ultimate architectural value of the Kotlin DSL in multi-module Android projects: Module scripts strictly declare module deviations. Common build rules are subsumed into compilable, testable, and reusable build logic.

If every module is a manufacturing assembly line, Precompiled Script Plugins are the "standardized equipment installation packages." The module doesn't manually install the toolchain line by line; it merely declares which standard equipment package it adopts, then supplies the module-specific parameters.

Migration Sequence: Start from the Clearest Boundaries

A mature Android project should never rename all Gradle files to .kts in a single devastating commit. The rational migration path tightens dynamic boundaries layer by layer.

Step 1: Upgrade the Wrapper and AGP/Kotlin Matrix

First, verify the compatibility matrix between the Gradle Wrapper, Android Gradle Plugin, Kotlin Gradle Plugin, and Android Studio. The official Android docs note that Android Studio Giraffe defaults new projects to the Kotlin DSL; if using AGP 8.1 and Kotlin DSL, Gradle 8.1 is the optimal baseline. Always defer to the latest AGP release notes for current versions.

This step isn't about chasing the cutting edge; it's about avoiding the misery of debugging historical Kotlin DSL defects on obsolete toolchains.

Step 2: Migrate settings.gradle

settings.gradle(.kts) possesses the most unambiguous responsibilities: plugin repositories, dependency repository strategies, version catalogs, and module includes. It generally lacks the dense Android plugin details found in module scripts, making it the ideal beachhead for migration.

Groovy:

pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = 'ZeroBugAndroid'
include ':app'

Kotlin:

pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = "ZeroBugAndroid"
include(":app")

Step 3: Establish Version Catalogs and Plugin Aliases

Consolidate plugin and library versions into gradle/libs.versions.toml. This allows subsequent module migrations to instantly leverage alias(libs.plugins...) and libs....

This step preemptively exposes naming friction. For instance, androidx-core-ktx generates libs.androidx.core.ktx; excessive nesting violently elongates invocation chains. Version Catalog aliases should prioritize script readability over blindly mimicking Maven coordinates.

Step 4: Extract Common Build Logic into build-logic

In multi-module projects, refrain from beautifying individual module scripts. Instead, identify repeating patterns:

Android application modules
Android library modules
Compose modules
Pure Kotlin/JVM modules
Test fixture modules
Publishing modules

Map each pattern to a convention plugin. Consequently, migrating a single module only requires:

plugins {
    id("zerobug.android.library")
}

Leaving behind only the module-specific namespace, dependencies, and minor variant configurations.

Step 5: Migrate Module by Module, Leaves Before Core

Prioritize migrating leaf modules with minimal dependencies and simple scripts. After migrating each module, execute:

./gradlew :module:help
./gradlew :module:assembleDebug
./gradlew :module:testDebugUnitTest

The help task validates the configuration phase; assembleDebug validates the Android build pipeline; unit tests validate test task execution and dependency configurations. Do not wait until all modules are migrated to run the first build; you will compress dozens of independent failures into a single, unreadable blast crater.

Root Causes of Common Migration Failures

Kotlin DSL migration errors rarely indicate "unfamiliar syntax"; they indicate the compiler mercilessly illuminating the latent dynamic assumptions hidden in your legacy scripts.

Unresolved reference: android

Typical Cause:

apply(plugin = "com.android.library")

android {
    namespace = "club.zerobug.core"
}

The android accessor was not generated because the plugin wasn't applied via an early plugins {} declaration. The immediate fix:

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

android {
    namespace = "club.zerobug.core"
}

If configuring the Android extension within a custom binary plugin, you cannot rely on script accessors. You must explicitly cast to the type:

class AndroidLibraryConventionPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.pluginManager.apply("com.android.library")

        project.extensions.configure<LibraryExtension>("android") {
            compileSdk = 36
        }
    }
}

Script accessors serve script compilation ergonomics; binary plugins are independently compiled Kotlin/Java code and must rely on concrete Gradle/AGP APIs.

Cannot get property ... on extra properties extension

Common Groovy pattern:

ext {
    compileSdk = 36
}

android {
    compileSdk rootProject.ext.compileSdk
}

You can begrudgingly read this in Kotlin DSL via:

val compileSdk: Int by rootProject.extra

But this is an architectural dead end. extra is a runtime key-value map; its type safety is atrocious, and mutation sources are impossible to track. The rigorous approach:

• SDK versions migrate to Convention Plugins.
• Dependency versions migrate to the Version Catalog.
• Environment variables and local configurations are read via the Provider API.
• Module-specific values remain hardcoded in the module script.

Type mismatch Exposes Old Implicit Conversions

Groovy cheerfully allowed fuzzy syntax:

compileSdk "36"
minSdk "26"

The Kotlin DSL demands reality:

compileSdk = 36
minSdk = 26

This is not migration noise; this is the necessary sterilization of type pollution within the build model. The more a build script relies on implicit coercion, the higher the probability it detonates at runtime during a future plugin upgrade.

The Divergence Between tasks.test {} and tasks.named<Test>("test")

The Kotlin DSL might generate accessors for core plugin tasks:

tasks.test {
    useJUnitPlatform()
}

However, in complex engineering, the universally robust and controllable pattern is:

tasks.named<Test>("test") {
    useJUnitPlatform()
}

named refuses to eagerly instantiate a task just to configure it, especially if that task won't even participate in the current build execution. This is paramount for Android multi-variant tasks: AGP spawns an avalanche of tasks per variant. Realizing them prematurely during the Configuration phase violently degrades IDE Sync and CI speeds.

Performance Trade-offs: Compiling Scripts Isn't Free

The official Android engineering blogs and migration docs caution against a stark reality: compiling a Kotlin DSL script is generally slower than parsing a Groovy DSL script, particularly during the initial sync or when the script classpath shifts.

This is not a defect; it is physics. Groovy DSL leans on runtime dynamic dispatch. Kotlin DSL must execute script compilation, type checking, accessor generation, and bytecode loading. It surfaces errors aggressively early, and the toll for that clairvoyance is upfront compilation work.

However, the Kotlin DSL offers formidable engineering compensations:

• Script compilation artifacts are cached in Gradle's local/remote cache.
• Accessors empower the IDE to perform surgical auto-completion, navigation, and refactoring.
• Type errors are caught instantly, eliminating late-stage CI pipeline failures.
• When paired with convention plugins, immense swaths of redundant script logic are eradicated, radically shrinking the total script volume and stabilizing the script classpath.

Therefore, performance analysis must transcend "which script parses faster on the very first run." It must be evaluated against long-term engineering operational costs:

Initial Migration Cost
  + Initial Script Compilation Overhead
  - Runtime errors from dynamic scripts
  - Configuration drift across duplicated scripts
  - The massive cost of IDEs failing to reliably refactor Groovy
  - The cost of untestable, un-modularized multi-module build logic

If a project has two modules and utterly stagnant scripts, the ROI on migration might lack urgency. But if the project spans dozens of modules, is maintained by a distributed team, and possesses constantly evolving build logic, the trinity of Kotlin DSL + Version Catalogs + Convention Plugins will dramatically collapse long-term architectural complexity.

A Practicable Android Migration Template

The following represents the optimal target architecture for mid-to-large Android projects.

Root settings.gradle.kts:

pluginManagement {
    includeBuild("build-logic")

    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")

rootProject.name = "ZeroBugAndroid"
include(":app")
include(":core:model")
include(":feature:feed")

Root build.gradle.kts:

plugins {
    alias(libs.plugins.android.application) apply false
    alias(libs.plugins.android.library) apply false
    alias(libs.plugins.kotlin.android) apply false
}

build-logic/src/main/kotlin/zerobug.android.application.gradle.kts:

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

android {
    compileSdk = 36

    defaultConfig {
        minSdk = 26
        targetSdk = 36
    }
}

app/build.gradle.kts:

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

android {
    namespace = "club.zerobug.app"

    defaultConfig {
        applicationId = "club.zerobug.app"
        versionCode = 1
        versionName = "1.0.0"
    }
}

dependencies {
    implementation(projects.core.model)
    implementation(projects.feature.feed)
    implementation(libs.androidx.core.ktx)
}

This architecture guarantees several profound engineering invariants:

• settings.gradle.kts dictates absolute project boundaries and repository strategy.
• The root script merely declares plugin versions; it bears zero business build logic.
• build-logic encapsulates and compiles all shared build rules.
• Module scripts are hollowed out, retaining only module identity, dependencies, and minute deviations.
• projects.core.model, libs.androidx.core.ktx, and id("zerobug.android.application") are fully inferable, auditable inputs—not scattered, fragile strings.

Post-migration, build scripts evolve from "every module writing its own custom configuration" to "modules declaring which canonical build convention they adopt." That is the true architectural deliverance of the Kotlin DSL in Android engineering.

Migration Checklist

During migration, methodically verify against this matrix:

Conclusion: The Goal is Compiler-Auditable Build Models

The paramount value of the Kotlin DSL is not "nicer autocomplete in Android Studio." It is the brutal forced march of the Gradle build model from the shadows of dynamic scripting into the light of compilable, navigable, refactorable software engineering.

Its underlying logic condenses into three sentences:

The plugins{} block declares dependencies upfront, defining the model's boundaries.
Gradle synthesizes Kotlin type-safe accessors based strictly on that known model.
The Kotlin compiler audits the build logic BEFORE execution ever begins.

Once this chain is understood, migration ceases to be a mechanical syntax replacement. It becomes a total architectural realignment: centralizing plugin versions, consolidating dependency coordinates, sinking shared rules into convention plugins, hollowing out module scripts, and forcing configuration-phase side effects into lazy Providers and explicit task models.

Such a build script operates like an industrial schematic, not a handwritten procedure. It demands rigorous boundaries, and in exchange, it empowers Gradle, the IDE, and CI to expose catastrophic flaws long before they ever reach production.

References

• Gradle User Manual: Kotlin DSL Primer
• Gradle User Manual: Migrating build logic from Groovy to Kotlin
• Android Developers: Migrate your build configuration from Groovy to Kotlin
• Android Developers Blog: Kotlin DSL is Now the Default for New Gradle Builds
• Gradle User Manual: Pre-compiled Script Plugins
• Gradle User Manual: Version Catalogs
• Gradle source: KotlinScriptEvaluator
• Gradle source: ProjectAccessorsClassPathGenerator