Every mature Android codebase eventually develops a silent, creeping tax: ProGuard bloat. Over years of development, as features are added, security frameworks integrated, and new third-party SDKs pulled in, mysterious runtime crashes occur. Someone pushes a fix:

# "Fixes ClassNotFoundException in release build"
-keep class com.thirdparty.sdk.** { *; }  

It works. The release build passes, the sprint finishes, and everyone moves on. Fast forward a few years. Your multi-module enterprise app takes 10 minutes to build, your APK download size creeps past 60 MB, and your cold-start launch time begins to climb. What happened?
Behind the scenes, those defensive blanket keep rules have essentially turned off your app optimiser.

Recently, our engineering team embarked on a mission to modernise our build infrastructure: upgrading to Android Gradle Plugin (AGP) 9 and undertaking a data-driven optimisation overhaul using R8 Full Mode.

When we ran our initial baseline audit, the results were a wake-up call: our app’s R8 optimisation score was a meagre 19.70%. More than 1.51 million methods, fields, and classes were completely frozen — immune to shrinking, inlining, class merging, or obfuscation.

Here is the story of how we fixed it: migrating to AGP 9, discovering the hidden gems in library-bundled rules, turning blunt wildcards into precision surgical rules, and pushing our optimisation score to 81.26% (and shrinking it to 81.64%) while unlocking 1.4 million code items.

Key Takeaways

1. The Problem: Upstream vendor AARs and transitive R classes silently locked 80.3% of our enterprise codebase from R8 optimisation, freezing 1.51M methods and fields and bloating our release APK across 18 Multidex shards.
2. The Migration: Upgraded to AGP 9.4.0 and Gradle 9.1.0, adopted built-in Kotlin (2.2.10) and modern Kotlin DSL (.gradle.kts), eliminated legacy multidex libraries, and enforced non-transitive R classes (android.nonTransitiveRClass=true).
3. The R8 Breakthrough: Leveraged AGP’s modern optimization.keepRules.ignoreFrom DSL to filter toxic upstream wildcard rules, swapped blanket rules for precision @Keep and member-level targets, and audited blast radius with R8’s Quantitative Configuration Analyser.
4. The Result: Uncompressed DEX shrank from 93.7 MB to 24.7 MB (-73.6%), locked code items plummeted from 1.51M to 97k (-93.6%), and 18 Multidex shards collapsed down to just 3 DEX files.

1. Setting the Stage: Upgrading to AGP 9 & Built-in Kotlin (Kotlin DSL).

Before you can optimise your code with modern R8, your build system needs to be running on modern foundations. AGP 9 represents one of the most significant architectural leaps in the Android tooling ecosystem in recent years.

Saying Goodbye to the External Kotlin Plugin

In previous versions of AGP, every module in a multi-module project had to declare:

// Kotlin DSL (build.gradle.kts)
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android") // Obsolete in AGP 9!
}

With AGP 9, Kotlin compilation is built directly into the Android Gradle Plugin. AGP 9.4.0 natively compiles Kotlin 2.2.10 out of the box. Removing the redundant external Kotlin plugin across our modules simplified our Gradle graph and unified compiler configuration under AGP’s modern built-in Kotlin DSL:

(Note: Built-in Kotlin in AGP 9 applies directly to pure Android application and library modules (com.android.application and com.android.library). Multiplatform setups (Kotlin Multiplatform / KMP) sharing cross-platform logic continue to use JetBrains’ org.jetbrains.kotlin.multiplatform plugin.)

// build.gradle.kts (or build.gradle)
kotlin {
    compilerOptions {
        freeCompilerArgs.addAll(
            "-opt-in=kotlinx.coroutines.ExperimentalCoroutinesApi"
        )
    }
}

(Note: Because built-in Kotlin targets modern Kotlin 2.x, default interface methods (-Xjvm-default=all) are enabled by default, and kotlin.RequiresOptIn is stable — allowing you to purge obsolete compiler flags.)

Modernising Annotation Processing: KSP and Legacy Kapt

While migrating from kapt to KSP (Kotlin Symbol Processing) is the recommended path for modern Android development, some enterprise codebases still rely on legacy annotation processors that do not yet support KSP. For these scenarios, AGP 9 provides a dedicated com.android.legacy-kapt plugin that bridges legacy processors with built-in Kotlin:

// Modern Kotlin DSL (root build.gradle.kts)
buildscript {
    dependencies {
        classpath("com.android.legacy-kapt:com.android.legacy-kapt.gradle.plugin:9.4.0")
    }
}

// Modern Kotlin DSL (app/build.gradle.kts)
plugins {
    id("com.android.application")
    id("com.android.legacy-kapt")
}    

Non-Transitive R Classes: Trimming the Resource Fat

While non-transitive R classes were introduced in AGP 7.0 and became the default in AGP 8.0, migrating legacy enterprise apps that previously opted out android.nonTransitiveRClass=false is essential to unlocking maximum build speed and R8 efficiency.

In legacy Android builds, each subproject module inherited the resource IDs of every dependency it touched. In a large app, this meant thousands of duplicate resource fields generated across dozens of intermediate R.class files.

Ensuring non-transitive R classes are active in gradle.properties:

android.nonTransitiveRClass=true

guarantees each module’s R class contains only the resources declared within that specific module. External resources must be referenced via their explicit package name (e.g., com.example.designsystem.R.color.primary).

This change prevents massive resource ID duplication across intermediate modules, dramatically accelerating incremental compilation and DEX packaging.

2. The Silent Optimisation Killer: R8 compatibility vs. Full Mode.

Most developers know that R8 replaced ProGuard as Android’s code shrinker. What many don’t realise is that for years, AGP operated in R8 Compatibility Mode by default.

What is R8 Full Mode?

• Compatibility Mode: Emulates legacy ProGuard behaviour. It makes conservative assumptions about reflection. If a class member is accessed or matches a rule, R8 often assumes the entire class might be accessed reflectively, preserving surrounding fields and methods.
• Full Mode: Strips unreferenced classes and interfaces, aggressively inlines single-use methods, merges interfaces with single implementations, and rewrites class structures.

In modern AGP, Full Mode is the default (unless disabled with android.enableR8.fullMode=false). When we enabled Full Mode, we ran R8’s Configuration Analyser using the Gradle flag:

./gradlew assembleRelease \
  -Dcom.android.tools.r8.dumpkeepradiustodirectory=$PWD/tmp/r8analysis

This dumps an empirical protocol buffer graph detailing every keep rule, where it came from, and how many classes, fields, and methods it prevents R8 from optimising (its blast radius).

(Along with the raw .pb protobuf dump, R8 automatically generates an interactive configanalyzer.html visualiser dashboard right inside your output directory, calculating overall optimization, shrinking, and obfuscation scores and highlighting top offending rules without requiring any custom parsing tools.)
The result was astonishing:

Baseline Analysis:
--------------------------------------------
Optimization Score : 19.70%
Shrinking Score    : 19.80%
Obfuscation Score  : 19.75%
Total Kept Items   : 1,516,929

Over 80% of our app was locked from optimisation.

The proof is in the APK: benchmarking compatibility mode vs. full mode & non-transitive R

To understand the real-world binary consequences of these configuration flags, we built and decompiled two production release APKs under identical release configurations (minifyEnabled true, shrinkResources true), isolating only the compiler and resource settings:

#Modern Full Mode Build (release-with-r8) 
android.enableR8.fullMode=true
android.nonTransitiveRClass=true
android.newDsl=false
android.uniquePackageNames=false

When we inspected the Dalvik executable headers across both APKs, the empirical difference was staggering:

Why Did Compatibility Mode and Transitive R Explode So Badly?

• The 971,000 Field Explosion (android.nonTransitiveRClass=false): In a multi-module architecture, transitive R class generation forces every downstream module to duplicate every resource ID from every dependency it touches. Combined with android.nonFinalResIds=false and vendor blanket keep rules (-keep class **.R$*), R8 was prohibited from inlining integer resource constants into call sites. This single issue caused over 1.1 million static fields to be locked into the APK! Enabling android.nonTransitiveRClass=true dissolved 971,962 redundant fields instantly (an 87.6% drop).
• Aggressive whole-app Optimisation in Full Mode (android.enableR8.fullMode=true): Compatibility Mode operates under conservative legacy ProGuard rules: if any class member is referenced or matched by a keep rule, R8 conservatively keeps the enclosing class structure and suppresses method inlining. Under Full Mode, R8 performs whole-app optimisation — merging single-implementation interfaces, inlining single-caller methods and constructors, and stripping unreferenced synthetic lambda classes. This eliminated 50,835 dead classes and 249,584 dead methods.
• Multidex Collapse (18 -> 3 DEX files) and Baseline Profile Optimisation: The Android DEX format imposes a strict 64K method/field reference limit per DEX file. Because compatibility mode + transitive R generated 1.1 million fields and ~395,000 methods, the compiler was forced to shard the application into 18 separate DEX files. During cold start, the Android Runtime (ART) must open, parse, verify, and memory-map each DEX shard. Collapsing 18 DEX files down to just 3 DEX files directly slashes classloader lookup contention and cold-start I/O overhead. Furthermore, by bringing the entire codebase down to fit within 3 shards, Android’s Baseline Profile compilation (dex-layout-optimizations) can group all critical launch classes into the primary classes.dex, ensuring peak startup performance without page-fault thrashing.

3. The Unsung Heroes: Benefiting from rules that libraries already shipped.

When looking through our application’s proguard-rules.pro, we noticed massive chunks of rules dedicated to third-party SDKs — FIDO biometrics, networking libraries, JSON parsers, and UI frameworks.

# Found in app/proguard-rules.pro:
-keep class com.security.fido.** { *; }
-keep interface com.security.fido.** { *; }
-keep class io.kotzilla.** { *; }
-keep class com.squareup.moshi.** { *; }
-keep class androidx.compose.** { *; }

Here was our first major breakthrough: Modern Android libraries already ship their own consumer ProGuard rules!

When an AAR dependency packages a proguard.txt or consumer-rules.pro, the Android Gradle Plugin automatically extracts and applies those rules during release compilation.

Because the library maintainers know their own internal reflection and JNI entry points far better than we do, their bundled rules are already calibrated to protect:

• Native JNI C++ methods (native <methods>;)
• JNI callbacks and reflection classes
• Internal serialisation interfaces

By writing blanket rules like -keep class com.security.fido.** { *; } in our application file, we were overriding the library author’s careful work and forcing R8 to keep thousands of internal helper classes, private methods, and unused features that the library authors never intended to preserve!

The Action:
We deleted dozens of redundant, defensive library keep rules from app/proguard-rules.pro. The result? Tens of thousands of unused classes from our dependencies were immediately dropped by R8, with zero runtime issues because the libraries’ own bundled rules kept what was actually necessary.

4. The Upstream Nightmare & AGP’s Filtering Superpower: ignoreFrom

Removing our own defensive rules was easy. But then we inspected the largest blast radius culprits in our R8 dump and discovered an alarming truth:

The worst keep rules weren’t in our codebase at all. They were inside third-party vendor AARs.

One upstream vendor SDK bundled this single rule in its proguard.txt:

# Inside vendor-sdk-1.0.aar:
-keep class **.R$* { <fields>; }    # Locked 812,831 items!
-keep class androidx.** { *; }       # Locked 235,231 items!

That one rule alone locked over one million code items across our entire application and disabled optimisation across all AndroidX libraries!
Historically, if a vendor packaged a terrible keep rule, Android developers had only two unpleasant options:

• Beg the vendor for an update and wait months.
• Write a custom Gradle transform script to unpack the AAR, delete proguard.txt, and repackage it.

Enter Modern AGP: ignoreFrom

While AGP 7.3 originally introduced ignoreExternalDependencies, modern AGP (AGP 8.4+ and AGP 9) refines and standardises this with the optimization.keepRules.ignoreFrom DSL (along with ignoreFromAllExternalDependencies = true).

(Note: ignoreFrom is currently an incubating AGP DSL feature, giving developers surgical control over upstream AAR consumer rules.)

It allows you to selectively tell R8 to ignore the bundled consumer-rules.pro from specific Maven coordinates during the merge phase:

// Modern Kotlin DSL (app/build.gradle.kts)
android {
    buildTypes {
        getByName("release") {
            optimization.keepRules {
                // Strip the toxic blanket rules from the vendor AAR:
                ignoreFrom("com.vendor.enterprise:problematic-sdk")
                ignoreFrom("org.conscrypt:conscrypt-android")
            }
        }
    }
}

By filtering out the vendor’s nuclear keep rule, we immediately regained control.

Pro Tip: You can inspect the merged output of all consumer rules before R8 runs by checking build/intermediates/proguard-files/ (or configuration.txt in your mapping outputs) to see exactly which vendor injected the offending keep rules.

Then, in our app/proguard-rules.pro, we added surgical replacement rules for only the exact runtime reflection classes that the vendor SDK actually needed:

# Surgical replacement: Keep only specific interfaces and caches
-keep @com.vendor.annotations.DoNotObfuscate class * {
     public <methods>;
     public <fields>;
}
-keep class com.vendor.modules.RendererCache {
     public <methods>;
     public <fields>;
}

Score Impact: Our optimisation score jumped from 20.74% to 54.11%, freeing nearly 600,000 code items in one stroke.

5. From Blanket to Scalpel: Surgical Keep Rule Patterns

Once the major external offenders were neutralized, we turned our attention to common architectural patterns that inadvertently freeze thousands of code items.

Pattern 1: Moshi JSON Serialization

In many Android apps, you’ll find a rule like this:

# The "Safe" Moshi Rule
-keepclassmembers @com.squareup.moshi.JsonClass class * {
    <init>(...);
    <fields>;
}

At first glance, this seems reasonable: if a class is annotated with @JsonClass, keep its constructor and its fields.

The Problem: <fields>; tells R8 to preserve every single private field across all your data classes. But in modern Android apps, models use Moshi’s annotation processor or KSP (@JsonClass(generateAdapter = true)).

When adapters are generated at compile time, Moshi bypasses reflective field access entirely: the generated adapter invokes public accessors or direct constructors. Keeping <fields>; was freezing every backing property for no reason.

All R8 needs is the un-obfuscated model class name (so Moshi can locate ${ClassName}JsonAdapter via reflection) and the target constructor.
We refined the rule to keep class names (so Moshi can locate the generated *JsonAdapter reflectively) and constructors invoked by the adapter:

-keepnames @com.squareup.moshi.JsonClass class *
-keepclassmembers @com.squareup.moshi.JsonClass class * {
    <init>(...);
}

(If your codebase still maintains models with reflective serialization using @Json, ensure the annotation explicitly targets the field via @field:Json or preserves public property accessors.)

Result: Over 9,400 private fields were instantly unlocked, allowing R8 to inline, rename, or eliminate them when unused.

Pattern 2: Security Providers & Native JNI (Conscrypt)

Conscrypt provides high-performance TLS/SSL encryption via native BoringSSL C++ code. Its bundled rule was a blunt package-wide keep:

-keep class org.conscrypt.** { *; }

This froze 4,910 classes, fields, and methods from optimization.

Because native C++ libraries interact with Java through the Java Native Interface (JNI), you must protect two things: the Java-to-C native method declarations and any Java callback classes/methods that C++ invokes via env->GetMethodID(…) or env->GetFieldID(…) — along with the Security.addProvider() entry point.

We ignored Conscrypt’s external rules and provided surgical JNI targets:

# Precision Conscrypt Rule
-keep class org.conscrypt.OpenSSLProvider { public <init>(...); }
-keepclassmembers class org.conscrypt.** {
    native <methods>;
}
# Preserve Java entry points and callbacks invoked by native BoringSSL code:
-keep class org.conscrypt.NativeCrypto { *; }

R8 was now free to optimise all internal Java plumbing, while native cryptographic calls continued to link flawlessly.

The Multiplier Effect: Collapsing the Transitive Blast Radius

When we neutralised the broad Moshi rules, Conscrypt’s package wildcard, and eliminated dead subsumed rules in our own configuration, the impact went far beyond those immediate classes. In R8, blanket rules create a cascading blast radius — forcing R8 to conservatively retain hundreds of transitive utility classes, companion objects, and interfaces that touch those hierarchies. Removing these roots collapsed the entire blast radius, unlocking over 400,000 dependent items in this final optimisation pass.

Pattern 3: Navigation SafeArgs & Code Annotations

Instead of keeping string patterns in ProGuard:

-keep class com.mycompany.app.presentation.common.error.ButtonAction { *; }
-keep class com.mycompany.app.presentation.common.error.ErrorType { *; }

We applied @androidx.annotation.Keep directly on the Kotlin enum declarations in code:

@Keep
enum class ButtonAction { RETRY, DISMISS, SUBMIT}

Keeping the rule in Kotlin source code colocates the optimisation requirement with the code itself, ensuring that if the class is ever deleted or refactored, the keep directive cleanly disappears with it.

The Keep Rule “Smell Test” Cheat Sheet

6. The Results: By the Numbers

Through four structured iterations of auditing, filtering, and refining, here is how the metrics evolved:

Milestone Evolution (At a Glance):

• Baseline: 19.70% Optimisation | 1,516,929 items locked (80%+ frozen)
• Round 1 (Dead App Rules): 20.74% Optimisation | Purged subsumed app rules
• Round 2 (Core Banking SDK): 54.11% Optimisation | Neutralised blanket vendor rules via ignoreFrom (+590,000 items freed)
• Round 3 (Features & Security SDK): 78.97% Optimisation | Isolated internal features & security wildcards (+326,000 items freed)
• Round 4 (Moshi & Conscrypt JNI): 81.26% optimisation / 81.64% shrinking | Precision JNI & Moshi codegen rules (+426,000 items freed)
• Total Net Gain: 97,576 kept items remaining (-93.6% / 1.42M items unlocked)

7. The 100% Optimisation Myth: Why you can’t (and shouldn’t) reach 100%

A common question engineering leaders ask when looking at optimisation dashboards is, "Why are we at 81%? Can’t we get to 100%?”

The short answer: If your native Android app reached 100% optimization, it would crash instantly on launch.

In native Android, approximately 15% to 20% of code must be kept intact by architectural necessity:

• OS Manifest Entry Points: Every activity, service, receiver, and contentProvider declared in AndroidManifest.xml must be located and instantiated reflectively by the Android Framework (ActivityThread via the application ClassLoader) using its exact class name.
• Native C/C++ JNI Tables: Libraries with .so binaries (biometrics, fraud detection, BoringSSL) look up Java methods via C symbol tables. If renamed or stripped, the app throws an immediate UnsatisfiedLinkError.
• Serialization Contracts: Network payloads exchanged with backend APIs require schema property names to remain consistent.
• Jetpack Framework Metadata: Jetpack Compose runtime group mappings and dependency injection (Koin) reflection require metadata preservation.

An optimisation score between 80% and 85% is the practical gold standard for a large enterprise Android app.

8. Five Rules of Thumb for Android Keep Rules in 2026

To keep your Android app lean and responsive, establish these practices across your engineering team:

1. Audit Upstream Rules First: When importing a new SDK, inspect its AAR’s proguard.txt. If you see -keep class **.R$* or -keep class com.package.** { *; }, don’t accept it. Use AGP’s optimization.keepRules.ignoreFrom and write surgical replacement rules.
2. Trust Good Libraries: Don’t write defensive “keep” rules for well-maintained libraries that already bundle their consumer rules. Let the library author’s rules do their job.
3. Never Use Package-Wide Wildcards: Replace -keep class com.foo.** { *; } with targeted entry points, interfaces, or @Keep annotations.
4. Distinguish Class vs. Member Keeps: If a class only needs reflection on its constructor, target it specifically: -keepclassmembers class com.example.MyClass { <init>(…); } or -keepclassmembers @MyAnnotation class * { <init>(…); }. Never write a catch-allclass * member keeps or retain <fields> ; unless reflective serialisation strictly requires it.
5. Measure Quantitatively: Don’t guess what your rules are doing. Run R8’s configuration analyser (-Dcom.android.tools.r8.dumpkeepradiustodirectory), inspect the blast radius, and make decisions based on real data. (Prerequisites: R8 9.3.7-dev+ / AGP 9.3+. The interactive configanalyzer.html opens directly in your browser, while raw protobuf data can be parsed via Python if running custom CI checks.)

Final Thoughts

Migrating to AGP 9 and optimising R8 is not just about improving the numbers on a chart. By reclaiming over 1.4 million code items from the frozen wasteland of blanket keep rules, we significantly trimmed our app’s binary footprint, improved method inlining and dead-code stripping, and established a faster, more resilient build pipeline. Take a look at your app’s proguard-rules.pro today. You might just find a million locked items waiting to be set free.