An Analysis of 120,000 Build Tool Invocations Across AOSP 15, 16 and 17
AOSP 17 has arrived, and most of the discussion will focus on what changed in Android itself: platform behavior, APIs, security, compatibility, and device-facing capabilities.
We looked somewhere else.
Instead of analyzing Android 17 as a product release, we analyzed it as a build system.
For Android platform teams, this matters because build infrastructure decisions are often based on an outdated assumption: that Android build performance is mostly a compiler problem. That assumption is still partially correct, but it no longer explains where Android build time accumulates at scale.
Using build telemetry from AOSP 15, AOSP 16, and the newly released AOSP 17, we examined the tools participating in the build, how often they execute, and how much cumulative execution time they consume.
The result is a view of AOSP 17 that does not appear in the release notes.
A single AOSP 17 build executes more than 120,000 build tool invocations across native compilers, linkers, Rust, Java, Kotlin, code generators, API analysis tools, ABI validation utilities, bytecode optimizers, and Android-specific processing stages.
That number matters, but not only because it is large.
It matters because of what it reveals about the shape of the build.
Clang remains the dominant workload, and any serious discussion of Android build performance must account for it. But across AOSP 15, 16, and 17, more work is being distributed across language-specific toolchains, generated-code stages, validation steps, transformation tools, and Android-specific utilities.
Some of these tools execute tens of thousands of times. Others execute only hundreds of times, but consume meaningful cumulative duration.
That distinction is where the story begins.
Modern Android builds are not just getting larger. They are changing shape.
For teams building Android at scale, the practical question is whether their build infrastructure is optimized for the Android build graph as it exists today, or for the simpler compiler-centric model of the past.
The most interesting story in AOSP 17 is not only in the release notes.
It is hidden inside the build graph.
The first question is simple: what runs during an AOSP 17 build?
The answer is more diverse than the traditional compiler-centric view suggests.
Native compilation is still the largest workload. In our AOSP 17 measurements, Clang was invoked 81,423 times, and the Clang linker was invoked another 9,064 times. Any serious analysis of Android build performance has to start there.
But the rest of the build is no longer marginal.
AIDL alone runs more than 23,000 times. Rust and Turbine are growing fast. And tools like Metalava and R8 execute only a few hundred times yet still consume meaningful build duration time. Below is the full breakdown.
| Tool | Invocations | Exec time (min) |
|---|---|---|
| Clang | 81,423 | 3,094 |
| AIDL | 23,422 | 17 |
| Clang linker | 9,064 | 91 |
| ABI Dumper | 2,059 | 68 |
| Rust Compiler | 1,824 | 165 |
| Java Compiler | 1,632 | 131 |
| Turbine | 1,344 | 47 |
| JarJar | 917 | 45 |
| YASM | 534 | 29 |
| Metalava | 332 | 85 |
| R8 | 137 | 84 |
| Kotlin Compiler | 128 | 85 |
| D8 | 109 | 13 |
Note: aggregate execution time is the sum of execution time across invocations and not wall-clock build duration
Wall-clock duration will be higher when sequential tasks are executed and lower if tasks can be executed in parallel.
The table exposes three useful patterns.
That distinction is important. A build dominated by one compiler can be optimized differently from a build composed of many tools with different execution profiles.
The release-over-release trend makes the pattern clearer.
| Tool | AOSP 15 | AOSP 16 | AOSP 17 | Growth |
|---|---|---|---|---|
| Clang | 75,363 | 77,412 | 81,423 | +8% |
| Rust Compiler | 1,135 | 1,615 | 1,824 | +61% |
| Java Compiler | 1,475 | 1,758 | 1,632 | +11% |
| AIDL | 22,181 | 23,381 | 23,422 | +6% |
| Turbine | 608 | 695 | 1,344 | +121% |
The trend is not that C++ is disappearing. It is not.
The trend is that the fastest-growing parts of the build are increasingly outside the traditional C++ compiler path.
From AOSP 15 to AOSP 17, Clang invocations grew by 8%. Rust compiler invocations grew by 61%. Turbine more than doubled. AIDL remained massive, with more than 23,000 invocations in AOSP 17.
This is the key observation from the data:
Android builds are not just growing. They are becoming more heterogeneous.
That matters because each tool family behaves differently. A generated-source step does not behave like a C++ compile. API analysis does not behave like Rust compilation. Bytecode optimization does not behave like linking.
The next question, then, is not only which tool is the largest.
It is how the build behaves when all of these tools execute together.
The AOSP 17 data matters because heterogeneous builds do not optimize like compiler farms.
In a compiler-heavy workload, the optimization model is relatively direct. If thousands of independent compilation actions are available, performance is mostly a function of parallelism, compute capacity, cache reuse, and scheduling efficiency.
A heterogeneous Android build behaves differently.
Many actions still parallelize well, especially native compilation. But other stages introduce ordering constraints, narrower parallelism, or downstream synchronization points. Generated sources must exist before dependent Java or native actions can proceed. API validation and ABI analysis depend on earlier build outputs. Bytecode transformation and packaging sit later in the pipeline and can influence final wall time even with relatively low invocation counts.
A simplified path might look like this:
The more teams accelerate Clang, the more the rest of the graph matters.
That does not mean Clang stops being important. The AOSP 17 data shows the opposite. Clang remains the largest individual workload by a wide margin. But optimizing the largest tool is not the same as optimizing the build.
AOSP 17 shows a build where performance depends on the interaction between multiple toolchains and processing stages. The important questions are no longer only:
They are increasingly:
These are graph-level questions.
They matter because Android is moving toward more languages, more generated code, more validation, more compatibility enforcement, and more specialized tooling. Each addition may be justified. Each may improve correctness, security, API discipline, or platform quality. But each also changes how work flows through the build.
That is the central lesson from the AOSP 17 build data.
The next major Android build bottleneck is not simply compiler performance.
It is the ability to execute, cache, and distribute work across the entire build graph.
Once Android build performance becomes a graph-level problem, clean build duration is no longer enough.
It still matters. But it is a summary metric, not a diagnostic one. It tells a team how long the build took. It does not explain which parts of the graph shaped wall time, which stages limited parallelism, or where the next optimization will actually pay off.
For AOSP-scale teams, three measurements become more useful.
First: critical path. Large Android builds contain thousands of actions that can run in parallel, but wall time is determined by the smaller set of actions that must execute in sequence. A tool can have modest aggregate duration and still matter if it sits on the critical path. Another tool can run thousands of times and have limited wall-time impact if it parallelizes well and avoids downstream synchronization.
Second: reuse. Modern Android development repeats similar work across developer machines, CI jobs, feature branches, release branches, validation pipelines, and automated tests. At that scale, the fastest action is the one that does not need to run again.
This makes cache coverage as important as cache speed. A cache that helps only one toolchain leaves much of the workload untouched. A cache that can reuse outputs across more of the graph changes the economics of repeated Android builds.
Third: distribution. Not every action can be skipped. Many actions still need to execute. The question is whether they are limited to the local workstation or can use available compute across developer machines, build servers, CI infrastructure, and cloud or on-prem resources.
These measurements become more important as development workflows change. AI-assisted coding will likely increase the number of build-triggering changes, implementation alternatives, refactorings, fixes, and validation cycles. That puts more pressure on CI throughput, queue time, cache reuse, and build execution capacity.
The pressure will not fall only on Clang.
It will fall on the full Android build workflow.
That is the operational implication of the AOSP 17 data. Android teams should stop evaluating build infrastructure only by compiler speed and start asking how efficiently the build graph moves work from input changes to validated outputs.
or many Android teams, the AOSP build is only part of the full product pipeline.
Device manufacturers, automotive Android teams, embedded teams, and platform organizations often build custom applications, system apps, vendor apps, launchers, services, middleware, and validation layers on top of the platform. Many of those components are built with Gradle and the Android Gradle Plugin rather than directly through the AOSP build system.
That adds another execution graph.
Gradle-based Android builds can introduce Kotlin and Java compilation, annotation processing, resource processing, manifest merging, D8 dexing, R8 shrinking, packaging, signing, tests, and dependency resolution. In large product environments, these stages can add meaningful duration to the total feedback loop.
Because developers experience platform builds, application builds, validation, and queueing as a single wait, the relevant metric is not only:
It is closer to:
The AOSP 17 data shows that the platform build itself is already heterogeneous. Real Android product builds often extend that heterogeneity further with Gradle-based workloads.
The implication is straightforward: an Android build acceleration strategy should account for the full product workflow, not only the platform compiler and not only the AOSP build.
If the optimization target is the graph, the acceleration layer has to operate across the graph.
That means two things.
First, repeated work should be reused. AOSP builds generate many opportunities for shared caching across developers, CI jobs, validation pipelines, release branches, and similar build inputs. When an output can be safely reused, the fastest build action is the one that does not run again.
Second, work that still needs to execute should not be limited to the local machine. AOSP-scale builds need to use available compute across workstations, build servers, CI infrastructure, and cloud or on-prem resources without forcing teams to migrate away from their existing AOSP build flow.
This is where graph coverage becomes decisive.
A strategy that accelerates only the dominant compiler can improve an important part of the build, but it leaves the rest of the workflow exposed. A strategy that covers compilation, linking, generated code, validation, Java and Kotlin processing, Rust compilation, bytecode transformation, packaging, and Android-specific tooling addresses the build as it actually behaves.
This is the approach Incredibuild is built around: shared caching combined with distributed execution, applied across the whole build graph rather than a single compiler. In our AOSP 17 benchmarks, combining shared caching with distributed execution produced the following results:
| Environment | Baseline | Accelerated | speedup |
|---|---|---|---|
| 16-core workstation | 3:51:53 | 0:17:42 | 13.1X |
| 32-core build machine | 2:02:05 | 0:15:18 | 8.0X |
The important observation is not only the speedup.
It is that the same approach continues to work as AOSP evolves. That is what we should expect when the optimization target is not a single toolchain, but the broader build workflow.
For Android platform teams, the practical implication is clear: build acceleration should be evaluated by graph coverage, cache reuse, distribution efficiency, and compatibility with the existing AOSP environment.
The organizations that scale best will not be the ones that optimize only the most visible compiler. They will be the ones that can execute the full Android build workflow more efficiently across developers, CI, product branches, validation pipelines, and increasingly, AI-assisted development.
Dori Exterman
Dori Exterman is incredibuild’s Chief Evangelist, previously serving as Chief Technology officer for over 15 years. incredibuild.com
Incredibuild empowers your teams to be productive and focus on innovating.
