R8 Configuration Analyzer: putting a number on how keep rules limit obfuscation

What happened on 2026-08-18

On 2026-08-18 (the blog's date, Pacific time), the Android Developers Blog published a Tinder case study introducing the R8 Configuration Analyzer. Per the post, the analyzer reports R8's effect as shrinking, optimization and obfuscation scores, and flags broad, redundant or obsolete keep rules, including consumer rules contributed by libraries. It is integrated into AGP 9.3, where release builds write a report to build/outputs/mapping/release/configanalyzer.html, and an analyzeReleaseR8Config task can generate it without a full release build. Tinder used the report to find a broad keep rule in an in-house library that blocked optimization across many dependencies; after refining it, R8 scores rose from 28% to 50%, and the post also reports cold-start and download-size improvements.

What it means for protecting app logic

The protection-relevant part is the obfuscation score: it measures how many classes, methods and fields R8 is able to rename. A single broad library rule can keep large parts of an app under original names without the team noticing. Names are the cheapest clue for both humans and AI tools reading decompiled code, so having an actual percentage is more honest than assuming obfuscation is on because minify is enabled. The boundary must be stated clearly, though: the score describes how much renaming and optimization R8 can perform, not how resistant the app is to analysis. String constants, control flow and network protocols remain visible, and a high score does nothing for hard-coded keys or rules shipped in the client.

Checks you can run

Generate the report on your own release build and start with the obfuscation score and the rules listed as broad, especially those coming from third-party libraries. Confirm whether each one is truly needed, for example for reflection, serialization or JNI entry points, and narrow it where you can. After narrowing, run end-to-end tests on a real release build, because keep-rule mistakes usually only surface at runtime. Following Tinder's approach, record the scores in CI so a new dependency cannot quietly lower them. Finally, make sure the mapping file is stored privately for crash retracing and never shipped with the app.

Your checklist

• Generate the R8 configuration report on a release build
• Narrow broad library keep rules and re-run release tests
• Track the obfuscation score in CI