R8 Configuration Analyzer Turns Keep Rules into Hard Numbers
Keep rules have been a blind spot: a single overly broad consumer rule from a library can silently block optimization across thousands of methods. This tool makes the cost visible and measurable, so teams can stop guessing and start trimming.
R8 Configuration Analyzer, now built into AGP 9.3, assigns a Shrinking Score, Optimization Score, and Obfuscation Score to a release build, quantifying the exact percentage of classes, fields, and methods still eligible for R8's transformations. A drop from 82% to 61% optimization after a dependency bump immediately flags the culprit. The tool maps every keep rule to its blast radius — the precise count of live classes, fields, and methods it locks out of optimization — and traces the rule back to its source file and Maven coordinate, including consumer rules buried inside third-party AARs. It also detects subsumed rules, where a broad wildcard already covers a narrower, redundant keep statement. Google ships an `r8-analyzer` Skill in the official `android/skills` repo that packages the entire workflow — running the analyzer, converting protobuf output to JSON, and generating a ranked report — into a scripted SOP a coding agent can execute. For projects stuck on older AGP versions, the Skill falls back to a heuristic path that flags package-wide wildcards and other high-impact patterns by syntax alone.
The analyzer closes a long-standing feedback gap: developers could write keep rules but had no way to measure their actual cost in lost optimization. Now that cost is a number that trends up or down with every config change.
Shifting the analysis from syntax to compiler-level program graphs means the tool sees the merged reality of all rules — including those injected silently by libraries — rather than just what's written in the app's own proguard file.
Packaging the analyzer as an agent-executable Skill signals Google's bet that keep-rule hygiene will become a routine, automated CI check rather than a manual audit.
The tool explicitly cannot prove a rule is safe to remove; it only quantifies the blast radius. The final call still requires runtime semantics knowledge — reflection, JNI, serialization — that static analysis cannot supply.