Debugging R8 Release-Only Crashes Without Disabling Optimization

A release build of an application may crash only after minification is enabled by R8, a code shrinking tool. Applying a simple fix such as -keep class com.example.** { *; } or disabling R8 entirely may hide the issue, but neither provides insight into the underlying problem. To effectively debug release-only R8 failures, treat them as indirect-reference debugging problems rather than attempts to guess ProGuard rules.

The goal is to identify runtime contracts that static analysis cannot see, preserve those contracts, and maintain optimization. Begin by reproducing the failure using the exact release variant that users experience, considering factors like build type, dependency graph, and generated code. Analyze the stack trace provided by R8, which can be preserved in mapping.txt for future reference.

Look for runtime mechanisms that expected the missing class, method, field, or other elements to remain discoverable. Common issues include reflection, runtime class loading, JNI, serialization frameworks, and dynamically discovered implementations. Problems often arise when the program encounters code in ways that static analysis cannot fully infer.

For example, using Class.forName(className) may introduce runtime dependencies that R8 fails to see. Investigate the rules applied by R8, as the configuration can come from various sources, including the application, Android tooling, and dependencies. Use the -whyareyoukeeping diagnostic rule to understand why specific classes are retained.

When writing keep rules, aim for the narrowest scope that expresses the runtime contract, rather than broad rules that keep excessive code. Prefer annotations to make the runtime contract explicit if your code intentionally exposes itself to reflection or discovery. By following these steps, developers can more effectively debug release-only R8 failures and ensure that optimization is applied correctly without disabling it entirely.