Google speeds up Android coroutine paths through R8
Google says Android developers can get faster coroutine launch and cancellation paths by moving to Android Gradle Plugin 9.2.0 or R8 9.2.0. In a post published on July 27, 2026, Android Toolkit engineer Andrei Shikov and R8 engineer Jonathan Starup explained that R8 now optimizes most Atomic*FieldUpdater calls into lower-overhead Unsafe variants when the compiler can prove the pattern is safe.
The practical target is Kotlin coroutine-heavy Android code. Google says the change has a large effect on kotlinx.atomicfu, the atomic operations library used by kotlinx.coroutines, and can make launching and cancelling coroutines up to 2x faster. The result matters most in UI paths that create short-lived coroutines frequently, including Jetpack Compose effects and interaction handling.
Why this bottleneck appeared
The Android Developers post describes a Compose performance investigation where coroutine setup and teardown became visible in method traces. Google cites Modifier.clickable as one example: before related performance work, most of the time spent creating and updating that modifier was consumed by launching and cancelling internal coroutines for InteractionSource updates.
The source of the overhead was not coroutine logic alone. The blog points to AtomicReferenceFieldUpdater, a JVM primitive used by kotlinx.atomicfu for lock-free atomic operations. Those updater calls rely on runtime field names and class references, so they include reflective access checks before reaching the underlying atomic operation. In Google's Pixel 5 benchmark on API 33, the kotlinx.atomicfu compare-and-set path measured 135 ns compared with 50.7 ns for AtomicReference, which Google described as about 2.7x slower.
What R8 changes
R8 already sits in the Android release build pipeline as a whole-program optimizer. The R8 project describes it as a tool that consumes Java bytecode and produces optimized DEX for Android apps. That full-program view is what lets the compiler recognize updater patterns that are statically obvious.
In the optimized case, R8 can keep the semantics of a valid updater while replacing repeated updater calls with direct Unsafe operations based on a field offset. Google breaks the implementation into instrumentation, replacement, and cleanup: R8 introduces offset fields, rewrites eligible call sites, preserves required null behavior, and removes unused updater setup when all uses can be optimized.
The important limitation is that this is not a blanket rewrite of every reflective atomic updater. The article says R8 targets most calls where the compiler can track the updater, holder type, and field type safely. Dynamic cases that do not satisfy those conditions can remain on the original path.
Why Compose developers should care
Compose leans on coroutines for controlled side effects. Android's Compose documentation explains that LaunchedEffect starts a coroutine when it enters composition and cancels it when it leaves; changing keys cancels the existing coroutine and starts a new one. That lifecycle is useful, but it means coroutine startup and cancellation costs can show up in UI-heavy workloads.
Google says Compose runtime microbenchmarks saw a 2x improvement when launching and cancelling coroutines in LaunchedEffect after the R8 update. Separately, the Android Runtime team is implementing related optimizations at the VM level. Google's article says apps targeting API 37 on recent Android versions may already see similar VM-side behavior, and its coroutine benchmarks observed about a 15% improvement after recent ART JIT updates.
What to do next
For teams shipping Kotlin-first Android apps, the action is straightforward: plan the move to AGP 9.2.0 or use R8 9.2.0 directly when your build constraints allow it. The benefit should be most visible in coroutine-dense code paths, especially Compose interactions and effects, but developers should still measure their own apps because the improvement depends on whether hot paths use optimizable atomic updater patterns.
This is a compiler and runtime story rather than a new API. Existing coroutine and Compose code can benefit without app-level rewrites, as long as the build uses the newer R8 path and the relevant code patterns are eligible for the optimization.