ProGuard configuration covers baseline code shrinking, obfuscation, and optimisation rules, while DexGuard configuration extends that model with additional hardening controls and Android-specific protection features. In practice, teams can often reuse existing ProGuard rules, but they must adapt them to fit the newer configuration model and remove overlapping Gradle settings.
Configuration scope and inheritance
ProGuard configuration is the baseline rule set for code shrinking, obfuscation, and optimisation in an Android build. DexGuard configuration sits on top of that idea, but it is not just a renamed ProGuard file. It adds product-specific hardening controls, so the practical difference is that DexGuard rules govern both the original shrinking model and the extra protections DexGuard introduces.
That matters when teams migrate an app or compare build outputs. A ProGuard file may still be partially usable, but DexGuard often expects a different configuration structure, different defaults, and separate knobs for features that ProGuard never handled. The safest mental model is that ProGuard rules are often a starting point, while DexGuard configuration is the fuller security and protection policy for the protected build.
- Reuse existing shrink and obfuscation intent where it still makes sense.
- Check whether a ProGuard directive has a DexGuard-specific equivalent or whether the setting should be removed.
- Review Gradle wiring carefully, because duplicated or conflicting build settings can create confusion even when the rules themselves are correct.
What DexGuard adds beyond the ProGuard model
DexGuard is designed for application hardening, so the configuration difference is not only about syntax but about scope. In addition to code shrinking and obfuscation, DexGuard can introduce stronger protection features that affect how code, resources, and build artefacts are defended at runtime and at rest. That is why teams should expect some ProGuard assumptions to stop being sufficient once they move into DexGuard territory.
The practical consequence is that migration is not a simple copy-paste exercise. Rules that only suppress warnings or keep classes available for reflection may still transfer, but anything tied to the older build pipeline needs validation against the protected APK, not just the source project. This is where teams should compare what the app must preserve for functionality with what the protection layer can safely transform.
How practitioners should approach migration and validation
What to verify: Confirm which rules are functional requirements and which are only build conveniences. Reflection-heavy frameworks, serialisation, and generated code are common places where a rule that worked in ProGuard may need adjustment in DexGuard.
Common mistake: Treating DexGuard as a drop-in replacement for ProGuard. That often leads to overlapping Gradle entries, missed hardening opportunities, or overbroad keep rules that reduce the value of the protection layer.
What good looks like: The app builds cleanly, expected classes remain reachable, unnecessary exceptions are removed, and the final protected package is tested on-device for both functional correctness and the intended hardening effect.
Practitioner takeaway: Use ProGuard rules as a migration input, not as the final authority. The right test is whether the DexGuard configuration preserves app behaviour while still allowing the additional protection features to do their job.
Risk and Threat Considerations
Configuration errors here can weaken both security and reliability. Overbroad keep rules may leave more code visible than intended, while mismatched migration settings can break runtime behaviour in ways that only appear after packaging, signing, or deployment.
Failure mechanism: Teams reuse legacy ProGuard directives without reconciling them with DexGuard’s extended protection model, or they leave overlapping Gradle settings in place. That can produce either accidental exposure of code paths and metadata, or functional regressions that bypass the intended hardening workflow.
Impact: The result is reduced protection value, harder troubleshooting, and a higher chance that the protected build is shipped with either weaker obfuscation than expected or avoidable application defects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Applies to Android build and hardening configuration control. |
| Recommendation — Harden Android build settings and remove conflicting legacy rules. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Fits the need to manage build protection processes and configuration consistency. |
| Recommendation — Standardise build protection procedures and validate protected releases. | ||
Related resources from NHI Mgmt Group
- What is the difference between build variant configuration and encrypted asset protection in Android apps?
- What is the difference between automatic project configuration and a compilation database for C and C++ code analysis?
- What is the difference between SaaS configuration and SaaS governance?
- What is the difference between sensitive environment variables and ordinary configuration values?
