Know what ProGuard changes
ProGuard removes unused classes, fields and methods, optimizes bytecode, and renames classes and members that are not kept as entry points. Resources can also be updated to follow changed class names. The output is smaller and harder to read because useful names have become short identifiers.
The missing names do not erase behavior. Android components still appear in the manifest. Retrofit annotations, URLs, JSON field names, protobuf schemas, error text and native method signatures can preserve strong leads. Framework keep rules often leave model classes or reflection targets readable.
Recover structure from behavior
We group classes by what they call and what data they handle. An obfuscated class that creates an OkHttp request, reads a token store and parses one response belongs to the network path regardless of its name. Cross-references rebuild meaning faster than renaming every class.
- Start at exported components and the target screen.
- Follow HTTP client creation, interceptors and serializers.
- Use string and resource references to join split code paths.
- Confirm the static path with one real request.
What a ProGuard project usually needs
Most ProGuard apps do not need unpacking or a special runtime. The effort goes into reconstructing class roles, state and request order. We deliver the target call with its authentication, signing and error rules, plus testable examples in the requested format.
Reviewed 30 August 2026 · SReverse research desk