Notifications
Clear all
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.
NHIMG editorial — based on content published by Guardsquare: From Keep Rules to Guided Configuration
Questions worth separating out
Q: How should teams handle reflection-heavy Android apps when using code shrinking?
A: Teams should inventory every runtime lookup path, then preserve only the classes and members those paths truly need.
Q: Why do keep rules often fail on the first attempt in protected Android builds?
A: They fail because static analysis cannot always infer which symbols are accessed dynamically at runtime.
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 dynamic lookup paths Identify every use of reflection, serialization, runtime class loading, and name-based field access in the app and its libraries before enabling aggressive shrinking.
- Separate library rules from application rules Review consumer rules supplied by dependencies and verify that they do not mask missing app-specific keep rules during release builds.
- Profile real user journeys before protection Run instrumented builds through login, onboarding, admin, and data-entry paths so automatic rule collection captures the flows most likely to fail.
What's in the full article
Guardsquare's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step debugging of the Moshi reflection crash and how each keep rule changes the stack trace.
- The exact guided workflow sequence for instrumentation, profiling, and protection in DexGuard.
- How the tool flags the User class after automatic rule collection and what that warning means operationally.
- The command-level workflow used to generate and protect the APK in a release-like pipeline.
👉 Read Guardsquare's guidance on keep rules and guided Android configuration →
Android keep rules and reflection crashes: what teams should know?
Explore further
18/08/2026 3:38 pm
Keep-rule drift is a configuration governance problem, not just a build issue. The article shows that app protection tools can invalidate runtime assumptions when dynamic code paths depend on names that obfuscation changes. That is a governance problem because teams must control which entities remain stable, why they remain stable, and who verifies that decision across release cycles. The practical lesson is to treat keep rules as security-sensitive configuration, not as one-off debugging artefacts.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: How do guided profiling workflows reduce risk in mobile app hardening?
A: They reduce risk by observing real execution paths and collecting keep rules from actual runtime behaviour instead of relying on guesswork. That gives teams a more complete starting point, provided they profile all critical journeys and still review the collected rules for unnecessary breadth.
👉 Read our full editorial: Guided keep rule workflows reduce Android reflection crash risk
