Gradle's incremental build feature avoids re-executing tasks whose inputs and outputs haven't changed since the last build, instead of rebuilding the entire project on every run. Gradle tracks this by hashing declared task inputs and outputs and comparing them against the previous build's state.
Key Points: • Each task declares its inputs (source files, properties) and outputs (compiled classes, generated files) via annotations like @InputFiles and @OutputDirectory. • Before running a task, Gradle checks if inputs/outputs match the last known state; if so, the task is marked UP-TO-DATE and skipped. • This works alongside the build cache, which can reuse outputs even across different machines or branches, not just the previous local build. • Incremental compilation (for Java/Kotlin) goes further, recompiling only the specific classes affected by a source change rather than the whole module. • The biggest advantage shows up in large, multi-module projects where a small change would otherwise trigger a full, slow rebuild.
Example: Changing a single method in one class within a 50-module project only triggers recompilation of that module and any modules that directly depend on its compiled output, while unrelated modules are skipped entirely and marked UP-TO-DATE.
Interview Tip: A concise interview answer is:
"Gradle tracks declared inputs and outputs for each task and skips any task whose inputs haven't changed since the last run, marking it UP-TO-DATE. Combined with incremental compilation and the build cache, this means a small code change only triggers rebuilding the affected pieces instead of the whole project, which is a huge win on large codebases."