Topic starter
18/08/2026 2:56 pm
TL;DR: Android apps can crash when R8 or ProGuard rename or remove classes and fields that reflection still needs, Guardsquare says. Android keep rule governance then has to balance crash recovery against the size and security trade-offs of broader preservation.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “From Keep Rules to Guided Configuration”.
Key questions
Q: Why do reflection-heavy Android apps need more careful keep rule governance?
A: Because reflection depends on runtime names that obfuscation and shrinking are designed to change.
Q: What do security teams get wrong about broad keep rules?
A: They treat broad preserve rules as a safe fallback, but those rules can weaken shrinking and obfuscation across far more code than necessary.
Q: What should teams do when an Android app crashes after enabling R8 or ProGuard?
A: Start by tracing the failing class or method back through the retraced stack trace and mapping file, then identify whether reflection or another dynamic lookup depends on names that optimisation changed.
Practitioner guidance
- Inventory reflection-dependent code paths Map every library and application path that relies on runtime symbol lookup, including JSON serializers, dependency injection, and plugin-style loading.
- Start with narrow keep rules Preserve only the classes, fields, or methods required to keep the observed behaviour working, then tighten any broad rule that protects more of the app than necessary.
- Profile representative user flows before release Exercise the app in an instrumented build across the screens and code paths where reflection occurs so runtime keep-rule needs are collected from actual behaviour rather than inferred after a crash.
Bottom line: Android optimisation can break apps when reflection depends on class or field names that shrinking and obfuscation change.
Glossary terms: Keep Rule, Reflection, Code Shrinking, Prompt Obfuscation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
18/08/2026 3:38 pm
Keep-rule precision is an application governance problem, not just a build task. The article shows that reflection-heavy Android apps can fail when optimisation changes the runtime contract between code and libraries. That means release engineering has to govern what must remain stable, not only what can be stripped away. Practitioners should treat keep rules as part of security and reliability policy, not a one-off fix.
A question worth separating out:
Q: When is guided profiling better than manual keep rule debugging?
A: It is better when an app has multiple reflective paths, mixed libraries, or a large codebase where crash-led iteration would take several build-test cycles. Guided profiling captures runtime behaviour directly, so teams can gather the needed rules in one controlled run instead of inferring them from repeated failures.
👉 Read our full editorial: Guided keep rule workflows reduce Android reflection crash risk