How should teams handle reflection-heavy Android apps when using code shrinking?

Why This Matters for Security Teams

Reflection-heavy Android apps are brittle under code shrinking because runtime behaviour depends on names, members, and classes that the compiler cannot always see. When R8 or ProGuard removes or renames code that reflection, annotations, serialization, or dependency injection expects, the app may pass build-time checks and still fail in production. That makes shrinking a correctness issue, not just an optimisation choice.

Security and platform teams should treat this as part of release engineering, because the same keep rules that preserve functionality can also preserve attack surface if they are too broad. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here for thinking about configuration control and least privilege in build pipelines, while NHIMG’s Ultimate Guide to NHIs shows why overexposed runtime access paths often become security debt later. The practical risk is that teams either overkeep everything or underkeep critical members, and both outcomes are costly.

In practice, many security teams encounter reflection-related breakage only after a release build has already shipped to a real device cohort, rather than through intentional shrinkage testing.

How It Works in Practice

The safest process is to map every runtime lookup path before tightening any rules. That includes Java reflection, Kotlin serialization, annotation processors, JSON mappers, dependency injection frameworks, Android resource lookups, JNI bridges, and any library that resolves classes by string name. Once those paths are known, teams can preserve only the exact classes, constructors, fields, or methods that must remain addressable.

In Android build terms, that usually means starting from a release-like build with shrinking, obfuscation, and optimization enabled, then running instrumentation tests and targeted manual flows. When a failure appears, use stack traces, logcat, or profiling to identify the missing symbol and add the narrowest possible keep rule. Best practice is evolving, but the current guidance suggests preferring targeted rules over broad package-wide exemptions. A rule that preserves a single annotation target is usually better than keeping an entire namespace alive.

Practical controls that help:

• Maintain an inventory of reflection entry points and generated-code assumptions.
• Test with release variants early, not only debug builds.
• Use mapping files and stack traces to trace obfuscation-related failures quickly.
• Review keep rules as part of code review, especially for libraries introduced by different teams.
• Re-run tests after dependency upgrades, because library internals and lookup conventions often change.

NHIMG’s Ultimate Guide to NHIs is relevant here because the same discipline applies to runtime secrets and service identities: preserve only what is required, and remove what is no longer needed. These controls tend to break down when apps depend on opaque third-party libraries, because the reflection contract may be hidden behind generated code or undocumented internal names.

Common Variations and Edge Cases

Tighter shrinking often increases debugging and maintenance overhead, requiring organisations to balance smaller attack surface and faster app startup against release friction and test complexity. The tradeoff is especially visible in apps that use frameworks such as Gson, Moshi, Room, Hilt, or older plugin systems, where class names or constructors may be discovered dynamically.

There is no universal standard for this yet, so teams usually adopt a layered approach: keep rules for documented framework requirements, explicit registration for custom reflectors, and automated tests that fail fast when a symbol disappears. For code paths that are intentionally dynamic, it is better to preserve a small, well-audited surface than to rely on blanket exclusions that hide future regressions.

One common edge case is feature delivery through app modules or plugins, where shrinkage may remove code that is only loaded in certain build flavours or during staged rollouts. Another is annotation-driven behaviour, where the annotation itself survives but the referenced member does not. Security teams should also watch for accidental overkeep of sensitive classes, because preserved internals can remain callable even when the application no longer needs them.

For broader governance, Ultimate Guide to NHIs and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the same operational idea: keep the runtime surface as small as possible, but prove that the remaining surface still works under real conditions.

Related resources from NHI Mgmt Group

• How should security teams handle trust assumptions when using ephemeral NHI credentials?
• How should security teams handle local accounts in cloud and SaaS apps?
• How should security teams handle secrets in AI-generated code?
• How should security teams handle OIDC client secrets in production apps?