R8 Analyzer: Shrink Your Android App Without Breaking It
What R8 is, why 'keep rules' quietly sabotage your app's size and speed, how Google's real R8 Configuration Analyzer measures the damage, and how to install and run the r8-analyzer AI skill with Claude Code — commands included for macOS, Linux, and Windows.
Author
Aman Kumar
Published
Aug 19, 2026
Read time
~10 minutes
TL;DR
R8 is the tool that shrinks, optimizes, and renames your app’s code before it ships. It works great — until your project accumulates keep rules (lines telling R8 “don’t touch this”), which is almost always true after a year or two of copy-pasted StackOverflow answers and library setup guides. Too many broad keep rules and R8 has nothing left to optimize.
”R8 Analyzer” actually refers to two connected things:
A real, Gradle-level measurement tool that generates hard numbers on exactly what R8 can and can’t touch.
A free Google AI agent skill that reaches the same verdict in plain English — using Method 1 automatically when it can.
This post explains both, how they fit together, and walks through installing and running the second one with Claude Code.
What R8 Actually Does
Every time you build a release version of an Android app, a tool called R8 (bundled inside the Android Gradle Plugin) processes your compiled code and does four things:
Shrinks it
Deletes code nothing ever calls.
Optimizes it
Inlines methods, merges classes, removes dead branches.
Obfuscates it
Renames PaymentValidator to a, verify() to b().
Shrinks resources
Strips unused drawables, layouts, and strings.
The result: a smaller, faster APK with no behavior change. Free performance, essentially — as long as R8 can actually see how your code is used.
Where It Breaks: Keep Rules
R8 works by tracing calls starting from your app’s entry points. But Android code routinely does things R8 can’t trace:
- Reflection —
Class.forName("com.foo.Bar"), where the class name is just a string. - JNI — native C/C++ code calling into Kotlin/Java by name.
When R8 can’t see a call, it assumes the code is dead and deletes it — and your app crashes at runtime with a ClassNotFoundException or similar. The fix is a keep rule in proguard-rules.pro, telling R8 “this specific thing is reached dynamically, leave it alone”:
This is exactly where things go wrong in most real projects. A developer hits a crash, doesn’t have time to write a precise rule, and instead pastes something like this:
-keep class com.example.package.** { *; }
That one line tells R8 to leave an entire package — and everything in it — completely untouched. Do that a few times across a few libraries, and R8 is running in name only: your “optimized” release build is barely smaller than debug.
The uncomfortable truth
Most Android projects that have been alive for more than a year are running R8 at a fraction of its potential — not because R8 is weak, but because of five or six overly broad keep rules nobody has revisited since they were added.
So What Is “R8 Analyzer”, Really?
Two different things share this name, and they’re not alternatives you pick between — one is built on top of the other.
The R8 Configuration Analyzer
A feature inside the Android Gradle Plugin / R8 itself. Point a release build at it, and it dumps raw, exact data — which classes, fields, and methods each keep rule is blocking, plus three headline percentages for your whole app.
The r8-analyzer Skill
A free instruction set published by Google at github.com/android/skills that teaches an AI agent (Claude, Gemini, etc.) how to read your project and reach the same verdict.
Here’s the part that isn’t obvious from the name: the skill’s first move is to try to run Method 1 for you. Opening the actual SKILL.md file shows it chooses between three paths depending on your project’s AGP and R8 versions:
Automatic
Runs a dedicated Gradle task that executes the real Configuration Analyzer directly, then parses its output.
Manual bridge
Manually triggers the same underlying measurement via a build flag, then converts and scores the raw data itself.
Heuristic fallback
Reads proguard-rules.pro by hand and reasons about each rule against Google’s own reference docs.
Which path will you actually hit?
Most real-world projects today — anything not on a bleeding-edge AGP alpha — land on Path C. That’s not a downgrade; it’s the same judgment a senior engineer would apply by eye, just automated and exhaustive. But understanding Paths A and B matters, because it explains why the skill sometimes narrates Gradle/Python steps instead of just answering — more on that in the troubleshooting section below.
Method 1: How the Real Analyzer Works
If you’re curious what Path A/B are actually doing, here’s the mechanism, end to end:
You run a release build with a special system property attached.
Instead of a human-readable file, R8 writes out a raw protobuf file — a compact binary format, not something you can open and read.
A conversion script turns that binary into JSON.
A scoring script reads the JSON and computes three percentages — Optimization, Obfuscation, and Shrinking — plus, per rule, exactly how many classes/fields/methods it’s blocking.
That pipeline is genuinely fiddly — binary parsing, a Python protobuf dependency, multiple intermediate files — which is precisely why the skill exists: it runs this whole chain for you and hands back only the final numbers.
If you want to trigger just the first step yourself, out of curiosity, here are the commands. Everything after this point (turning the raw file into real numbers) is the part meant to be automated, not hand-run.
Requirement
9.3.7-dev or later for this to produce anything at all.mkdir -p "$PWD/tmp/r8analysis"
Creates a scratch folder to hold the raw output.
./gradlew assembleRelease -Dcom.android.tools.r8.dumpkeepradiustodirectory=$PWD/tmp/r8analysis
Runs a release build with the analyzer flag attached.
If your R8 version is new enough, you’ll find .pb files sitting in that folder afterward — confirmation the measurement ran. If nothing appears, that’s not a mistake on your part; it just means your project isn’t there yet, and Path C is the right tool for you today.
Method 2, Step by Step: Installing and Running the AI Skill
1. Prerequisites
If you don’t already have Claude Code:
npm install -g @anthropic-ai/claude-code
Identical on macOS, Linux, and Windows — it’s an npm global install.
2. Install the skill into your project
The skill is just a folder of Markdown files sitting in Google’s public repo. You’re going to pull out only that one folder, using Git’s sparse-checkout feature.
Ten small steps, each its own copyable command. The Git commands are identical on every OS — only the local file-moving commands at the end differ, so those get a macOS/Linux ↔ Windows tab switcher. Expand the box below to walk through them.
3. Run it
From your project root, start Claude Code:
claudeThen, inside that session, either type the slash command:
/r8-analyzer
or just ask in plain English:
Run the r8-analyzer skill on this project
The agent reads SKILL.md, decides between Path A / B / C as described above, then works through your actual build.gradle, gradle.properties, and every proguard-rules.pro / consumer-rules.pro file it can find.
4. Where the results actually show up
Directly in the chat
A raw Markdown report — a “Configuration” section (if relevant), an “Optimization Summary,” and a per-rule breakdown
labeling each rule Remove or Refine, with a reason. That’s it.
No file gets written to your project. Copy the report out of the terminal into wherever you want to
keep it — a PR description, a wiki page, a .md file you save yourself.
5. Apply, rebuild, repeat
The skill only suggests — by design, it will never touch proguard-rules.pro itself. Review the report, apply whatever you agree with yourself, rebuild your release variant, run your tests, and re-invoke /r8-analyzer any time you want a fresh pass.
”It Just Told Me What It Was Going to Do”
Closing thought
Most of the “R8 isn’t shrinking my app much” complaints aren’t an R8 problem at all — they’re a handful of forgotten, overly broad keep rules quietly eating all the optimization budget. You don’t need to memorize the ProGuard rule syntax, the impact hierarchy, or a protobuf pipeline to find them. You need ten minutes to install a free skill and let an agent read the files for you.
The tool is free, the setup is one script, and the worst case is it tells you your config is already fine.