Actualité
Google says R8 9.2.0 can make Kotlin coroutines up to twice as fast
Google’s Android tooling team says a new R8 optimization in Android Gradle Plugin 9.2.0 can significantly reduce the cost of Kotlin coroutine operations in apps.
Google’s Android tooling team says a new optimization in R8 can make important Kotlin coroutine operations substantially faster in Android applications. In an official Android Developers Blog post published on July 27, 2026, engineers Andrei Shikov and Jonathan Starup explain how Android Gradle Plugin 9.2.0 optimizes common uses of Java’s Atomic*FieldUpdater classes.
The change is aimed at developers rather than phone owners. It is included in Android Gradle Plugin 9.2.0, and developers can also use R8 9.2.0 directly. The optimization is applied during the build process, so it can improve application code without requiring a new Android operating-system feature or a redesign of the app.
Why coroutines were losing time
Kotlin coroutines are widely used for asynchronous work in Android applications. They are also deeply integrated into Jetpack Compose, where they can manage interactions, animations and other operations outside the main composition flow. Google’s investigation found that coroutine setup and cancellation could become a measurable source of overhead in frequently executed paths.
The developers use Modifier.clickable as an example. In their analysis, launching and cancelling internal coroutines accounted for about 80% of the time spent creating and updating that modifier in the scenario they examined. That figure describes the team’s investigated workload, not a universal measurement for every Android application, but it illustrates why small costs inside coroutine machinery can become visible in user-interface code.
The underlying issue was connected to kotlinx.atomicfu, the library used by kotlinx.coroutines for atomic operations. Its implementation can rely on AtomicReferenceFieldUpdater, which performs reflective checks before accessing a field. Each check is relatively small, but starting, suspending, cancelling and completing coroutines can involve many atomic operations.
What Google measured
To separate runtime behaviour from compiler assumptions, the team used Android benchmarks and ART method traces. In one benchmark on a Pixel 5 running API 33, a direct AtomicReference operation measured 50.7 nanoseconds, while the corresponding kotlinx.atomicfu operation measured 135 nanoseconds before the new optimization. Google describes the latter as approximately 2.7 times slower in that test.
R8 addresses the gap by examining whether an updater is used in a predictable, statically verifiable pattern. When it can prove that the holder class, field type and accessed field are valid, R8 can replace the reflective updater call with an internal Unsafe operation. The generated code can then work with a field offset instead of repeating the updater’s reflective validation.
The transformation has three broad stages. R8 first instruments eligible updater fields, then replaces qualifying call sites with direct atomic operations, and finally removes the temporary fields and initialization code when they are no longer needed. If a use cannot be proven safe, the original implementation remains in place. That fallback matters because updater classes also support dynamic and reflection-heavy patterns that cannot safely be simplified at compile time.
Compose sees the clearest benefit
Google reports that the main beneficiary was Jetpack Compose. After updating R8, Compose runtime benchmarks recorded a twofold improvement in the time required to launch and cancel coroutines used by LaunchedEffect. The result is especially relevant to apps that frequently create short-lived asynchronous tasks in response to interaction or changing UI state.
The blog also says that optimized kotlinx.atomicfu operations and most explicit uses of the updater classes can reach performance comparable to AtomicReference. In some benchmarks they were faster, partly because the atomicfu compiler plugin can inline atomic instances into fields and reduce allocations.
There is a second layer of improvement in newer Android runtimes. Google says the Android Runtime team is implementing similar optimizations at the virtual-machine level. In the coroutine benchmarks cited by the post, recent ART Just-in-Time updates produced an additional improvement of around 15% on a device targeting API 36. That result depends on the runtime and device, so it should not be treated as a guaranteed gain for every app.
What developers should do
For developers maintaining an Android application, the practical step is to evaluate an upgrade to Android Gradle Plugin 9.2.0 or later, then compare release and benchmark builds against the existing toolchain. The optimization is most relevant to apps that use Kotlin coroutines heavily, rely on Compose interactions or spend measurable time launching and cancelling short-lived jobs.
Teams should still check build compatibility, inspect generated output where performance is critical and repeat their own benchmarks on supported devices. Google’s published measurements demonstrate the potential of the change, but they do not promise a universal twofold improvement in complete application startup time, frame rate or battery life. The benefit will depend on how much coroutine and atomic-operation overhead exists in a particular app.
That distinction makes this a useful tooling update rather than a marketing claim about a new phone. Users may experience smoother interaction in some applications after developers rebuild them with the newer toolchain, but the result is indirect and application-dependent. For Android teams already preparing their projects for the next generation of platform and Compose tooling, R8 9.2.0 offers a targeted way to reduce concurrency overhead without changing the app’s public behaviour.