Speeding Up Gradle Builds: What Actually Made a Difference

I shipped my first Android app in 2012, when Gradle was still the new kid on the block and clean builds took a coffee break. Thirteen years and 22 apps later, I have spent more hours than I care to admit staring at a spinner. Most "speed up your Gradle build" posts recycle the same five tips. This one is different. I am only writing about the changes that actually moved the needle on real projects, with the numbers I measured.

If you maintain a medium to large Android codebase and your CI feels like a tax, this is the playbook.

The Baseline: What Slows a Gradle Build Down

Before tuning anything, I profiled. Gradle's

--profile

:app:processDebugResources

On my current project, a single-module app with around 90k lines of Kotlin, the baseline numbers looked like this:

Two things jumped out. First, KAPT was eating a huge slice of configuration time. Second, every clean build downloaded and processed the same dependencies from scratch, even when nothing in

build.gradle.kts

[!NOTE] Always run with

code Copy

--profile

before optimizing. Without data, you are guessing. Guessing with Gradle is a great way to spend a day making things worse.

The Changes That Actually Helped

I tried roughly a dozen tweaks over six months. Five made a measurable difference. The rest were either neutral, already enabled, or actively harmful. Here is what worked, in order of impact.

1. Migrating off KAPT to KSP

KAPT runs the Java annotation processor pipeline for every Kotlin file. It is slow, it duplicates work, and it has been officially discouraged for years. KSP does the same job by reading Kotlin's own AST directly.

The migration for my Hilt and Room setup took an afternoon. The configuration change:

// build.gradle.kts (project)
plugins {
    id("com.google.devtools.ksp") version "2.0.21-1.0.27" apply false
}

// build.gradle.kts (app)
plugins {
    id("com.google.devtools.ksp")
}

dependencies {
    implementation("androidx.room:room-runtime:2.6.1")
    ksp("androidx.room:room-compiler:2.6.1")
    implementation("com.google.dagger:hilt-android:2.51.1")
    ksp("com.google.dagger:hilt-android-compiler:2.51.1")

    // Replace any kapt(...) lines with ksp(...)
}

[!IMPORTANT] If you still use kapt anywhere, the build pays a tax on every single Kotlin compilation. The KSP migration was the single biggest win I have ever seen on Android build performance.

Cold build dropped from 4m 12s to 3m 04s on the same machine. Configuration time alone fell by roughly 40 percent.

2. Enabling the Build Cache Properly

Gradle's build cache stores task outputs by their inputs. Reuse them and you skip work that has already been done. The trick is making sure the cache actually has a home and CI knows about it.

Locally, I set a fixed cache directory so different projects stop fighting over the default location. On CI, I point at a remote cache backed by object storage.

// settings.gradle.kts
pluginManagement {
    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}

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

// Enable build cache and configure remote cache for CI
buildCache {
    local {
        directory = File(System.getProperty("user.home"), ".gradle/caches/build-cache")
        removeUnusedEntriesAfterDays = 30
    }
    remote(HttpBuildCache::class.java) {
        url = uri("https://cache.example.com/gradle-cache/")
        isAllowInsecureProtocol = false
        // Push only from CI to avoid local machines spamming the remote
        isPush = System.getenv("CI") != null
        credentials {
            username = System.getenv("CACHE_USER") ?: ""
            password = System.getenv("CACHE_TOKEN") ?: ""
        }
    }
}

On CI, warm build times fell from around 90 seconds to under 25 seconds because the same Maven artifacts and intermediate outputs from the previous run were reused.

[!TIP] Use a separate

code Copy

~/.gradle/caches/build-cache

directory per project if you work on several. The default cache mixes projects, and a corrupted entry from one repo will poison another.

3. Splitting the App Module by Feature

For years my projects were single-module. It is the path of least resistance, and the path of slowest builds. Every change recompiled the entire codebase.

I split the project into a

:core

:app

// settings.gradle.kts
include(":app")
include(":core")
include(":core:network")
include(":core:database")
include(":feature:home")
include(":feature:settings")
include(":feature:billing")

// feature:home/build.gradle.kts
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
    id("com.google.devtools.ksp")
}

android {
    namespace = "com.sudarshantechlabs.feature.home"
    compileSdk = 35
    defaultConfig {
        minSdk = 24
    }
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
    kotlinOptions {
        jvmTarget = "17"
    }
}

dependencies {
    implementation(project(":core"))
    implementation(project(":core:database"))

    implementation("androidx.compose.ui:ui:1.7.5")
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.8.7")
    implementation("androidx.hilt:hilt-navigation-compose:1.2.0")
}

The first time I touched only

feature:home

feature:billing

core:network

[!WARNING] Module splits have a real cost. Every

code Copy

internal

symbol you want to share has to either become

code Copy

public

or move to a

code Copy

:core

module. Decide before you start splitting. A messy split is worse than a slow single module.

4. Disabling Unnecessary Build Features

Some features look free and are not. In every project I run, I now disable three things by default: BuildConfig generation, vector drawable rasterization for old API levels, and the resource shrinker on debug builds.

// app/build.gradle.kts
android {
    buildFeatures {
        buildConfig = false
        // Only enable when you actually use it
        // aidservice = true
    }

    defaultConfig {
        // minSdk is 24 in my projects, so PNG rasterization is dead weight
        vectorDrawables {
            useSupportLibrary = false
        }
    }

    buildTypes {
        debug {
            isMinifyEnabled = false
            isShrinkResources = false
        }
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

buildConfig = false

5. Parallel Execution and Configuration on Demand

Two Gradle properties do most of the heavy lifting. Add them to

gradle.properties

# gradle.properties
org.gradle.jvmargs=-Xmx4g -Dfile.encoding=UTF-8 -XX:+UseParallelGC
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configureondemand=true

org.gradle.parallel=true

org.gradle.configureondemand=true

[!TIP] If you use Android Studio, also bump

code Copy

-Xmx

to at least 4 GB. Default heap allocation is 512 MB, which forces frequent GC pauses and is a leading cause of "the IDE is sluggish" complaints that are actually Gradle complaints.

What Did Not Help

I want to be honest about the things that did not matter.

Switching from Groovy to Kotlin DSL in

build.gradle

Removing

apply plugin

plugins {}

Adding

--offline

Generating sources once via

ksp { arg("room.schemaLocation", ...)}

Where I Landed

After all changes, the same project looks like this:

The warm build number is what changed my day-to-day life. Sub-10-second builds on a medium-sized app means I stay in flow. I do not context-switch. I do not check Slack while waiting. That is worth more than any of the headline cold-build savings.

Key Takeaways

• Migrate from KAPT to KSP today. It is the single largest Android build performance win available right now, and it is a one-afternoon change for most projects.
• Set up a real build cache, both local and remote. Use a dedicated
  code Copy

  ~/.gradle/caches/build-cache

  directory per project, and only push to the remote cache from CI.
• Split your app into feature modules before you split anything else. Incremental builds of one feature dropping to under 10 seconds is what actually changes how you work.
• Disable
  code Copy

  buildConfig

  , debug resource shrinking, and old vector rasterization. Each costs seconds per build with no development benefit.
• Tune
  code Copy

  gradle.properties

  last.
  code Copy

  org.gradle.parallel=true

  ,
  code Copy

  org.gradle.caching=true

  , and
  code Copy

  -Xmx4g

  are mandatory, but they are finishing moves, not opening moves.

The boring truth is that build performance is a stack. The base layer is what Gradle is asked to do, and that is shaped by your build files. The middle layer is parallelism and caching. The top layer is your machine. Fix the base first. Everything else is decoration.