R8 vs ProGuard: Shrinking, Optimization and Compatible Rules

Identify what the build actually runs

In a current Android Gradle Plugin project, enabling code optimization invokes R8. A file named proguard-rules.pro does not prove that the ProGuard executable ran: R8 consumes compatible rules from that file.

Use the Android optimization documentation for Android configuration and the ProGuard manual for a standalone ProGuard pipeline. Mixing commands from the two can create misleading diagnostics.

Compare the responsibilities

Both can remove unused code and rename symbols. Neither turns an embedded API secret into a safe secret.

Migrate rules, not assumptions

Start with the rules actually required by reflection, serialization, native interfaces and libraries. Remove obsolete broad keeps only with release tests. The keep-rule guide explains why retaining every class defeats much of the optimizer's value.

A third-party library may already supply consumer rules. Check those before adding a second app-wide rule that keeps an entire package. A rule that once worked around an old optimizer bug may no longer be necessary, but deleting it without reproducing its original case is also risky.

Compare release outcomes

Measure the same variant, resources, ABI configuration and dependency set. Compare artifact size, startup and critical flows after shrinking. A smaller APK with broken reflective deserialization is not an improvement.

Archive mapping files for each distributed release. Debug builds do not exercise the same optimization behavior and cannot establish release compatibility.

Use inspection as a supporting signal

APKLint's ProGuard / R8 checker can highlight likely obfuscation characteristics. It cannot identify every transformation or certify that your rules are correct. The decisive evidence is a successful optimized build, representative runtime tests and usable crash deobfuscation.