Topic starter
18/08/2026 2:56 pm
TL;DR: Android optimizers such as ProGuard and R8 can break apps when reflection-dependent classes are renamed or removed, and that debugging keep rules often requires iterative crash analysis, according to Guardsquare. Its guided workflow claims to collect the needed keep rules during instrumentation so teams can configure protection with less trial and error.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “From Keep Rules to Guided Configuration”.
Key questions
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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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