ProGuard for Java vs R8 for Android: Choose the Correct Pipeline

Start with the output platform

The ProGuard manual describes its Java-oriented processing pipeline. Android projects should start from the R8 integration guide.

A shared Java library may be processed differently depending on whether it is distributed as a library or incorporated into an Android app. Do not run multiple transformation stages without understanding how mappings and public APIs survive.

Identify input and library code

Application input is transformed. Library code supplies types and relationships needed for analysis but is not simply interchangeable with the program input.

Missing platform or dependency classes can generate warnings. Suppressing all warnings hides analysis gaps; determine whether a dependency is genuinely optional, incorrectly supplied or absent from the runtime.

Keep public contracts deliberately

For a reusable library, public API names, reflective access and serialization contracts can matter to downstream consumers. An application can often optimize more aggressively because it controls the whole program.

Configuration syntax overlap does not guarantee identical support for every option or processing assumption.

Preserve useful diagnostics

Archive the mapping associated with the exact transformed output. Rebuilding later from apparently identical source may not reproduce the same mapping if dependencies or tooling changed.

Test reflection and serialization with the processed artifact, not just unprocessed unit-test classes. Keep a minimal reproducer for any rule added to solve a compatibility failure.

Apply APKLint at the right stage

APKLint's obfuscation checker is useful for examining an Android package after the build. It is not a replacement for running ProGuard on Java inputs and cannot validate a standalone Java distribution. Choose the build pipeline first, then use artifact inspection to check the result it actually produced.