Build Analyzer in Android Studio

Build Analyzer is a tool in Android Studio that helps developers detect and resolve build performance issues by surfacing detailed data about which Gradle tasks and plugins contribute most to build time. By comparing reports across builds, you can identify regressions, pinpoint slow tasks, and apply targeted optimizations. By the end of this lesson, you will be able to:

• Explain how Build Analyzer surfaces task level build performance data.
• Identify common warnings such as always-run tasks and non-incremental annotation processors.
• Use the plugins view to isolate which plugins introduce expensive tasks.
• Detect regressions by comparing build reports over time.
• Act on configuration cache and Jetifier recommendations from Build Analyzer.

Accessing Build Analyzer

Each time you run a build, Build Analyzer generates a report accessible via View > Tool Windows > Build > Build Analyzer. The report highlights tasks that impact build duration, ordered by execution time. This gives you an immediate view of where time is being spent.

The report is generated per build, so you can compare it across successive builds to spot regressions. If a task that previously took 2 seconds starts taking 15 seconds after a dependency upgrade, the Build Analyzer report will surface that change.

Task and Plugin Insights

The Plugins with tasks impacting build duration view groups tasks by the plugin that registered them. This helps you identify whether a slow build is caused by your own custom tasks, a third-party plugin, or the Android Gradle Plugin itself.

Within each plugin group, tasks are ordered by execution time. You can drill into individual tasks to see their inputs, outputs, and whether they ran incrementally or from cache. This breakdown is useful when you have dozens of plugins and cannot tell from the total build time which one introduced a regression.

For example, if you upgrade a code generation plugin and your build time increases by 20 seconds, the plugin view will show the specific tasks registered by that plugin and their individual execution times. You can then compare these times against the previous build report to confirm the source of the regression.

Common Warnings

Build Analyzer flags several categories of inefficiency:

Always-run tasks execute on every build because they have missing or incorrect input/output declarations. Gradle cannot determine whether the task's output is up to date, so it runs the task unconditionally. Fixing the input/output declarations lets Gradle cache the result and skip the task when nothing has changed.

A properly declared task looks like this:

abstract class GenerateConfig : DefaultTask() {
    @get:Input
    abstract val appVersion: Property<String>

    @get:OutputFile
    abstract val outputFile: RegularFileProperty

    @TaskAction
    fun generate() {
        outputFile.get().asFile.writeText(
            "version=${appVersion.get()}"
        )
    }
}

The @Input and @OutputFile annotations let Gradle track whether the task is up to date. Without them, Gradle assumes the task must always run.

Task setup issues occur when multiple tasks write to the same output directory. This invalidates caching because Gradle cannot attribute outputs to a specific task. The fix is to give each task its own output directory.

Non-incremental annotation processors force full recompilation of all annotated classes whenever any source file changes. Migrating to an incremental processor or switching to KSP reduces the scope of recompilation to only the files that actually changed. Build Analyzer lists which annotation processors are non-incremental, making it straightforward to prioritize migration efforts.

Configuration cache compatibility is checked by Build Analyzer. When compatible, enabling the configuration cache lets Gradle reuse the task graph from previous builds, skipping the configuration phase entirely. Build Analyzer identifies which tasks or plugins block compatibility and provides guidance on fixing them.