ProGuard transformations can affect analysis cost. Treating them as equivalent to integrity verification, root assessment or server enforcement creates incorrect expectations.
Evaluation approach
Renaming classes and members influences analysis. Configure keep rules correctly for dynamically accessed code.
Application example
When shrinking a library, preserve its external API contract and test whether renaming affects serialization.
Limits and considerations
A successful obfuscation report does not establish root, hooking or package-integrity checks.
Preserve the contract when publishing a library
Public APIs, serialized fields and reflectively accessed elements may need preservation during transformation. Unnecessarily broad keep rules reduce shrinking and obfuscation benefits. Document why each rule exists.
Test a release build through a sample consumer. Store mapping files securely with the correct version. A successful ProGuard output does not establish added runtime-environment or interference checks; meet those requirements separately.
Checks and decisions
- Review keep rules
- Retain mapping files
- Verify release behavior
Assess ProGuard as a build tool and define required RASP capabilities separately.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.