Android App Obfuscation: Raise Analysis Cost, Do Not Hide Secrets

Define the threat first

Protecting intellectual property, reducing package size and preventing backend abuse are different goals. R8 can support the first two, but backend authorization still belongs on the server.

The Android security guidance should drive storage, transport and trust decisions. Avoid using obfuscation as a substitute for access control.

Separate three transformations

The R8 documentation explains the Android build integration. An APK containing short class names is evidence of renaming, not proof of a complete protection strategy.

Remove secrets instead of disguising them

A private service credential should not be embedded in Kotlin, native code, resources or an encrypted asset whose key also ships in the app. Move privileged operations behind an authenticated, authorized backend.

Public configuration identifiers are a different category. Review each value according to its permissions and abuse potential rather than treating every string containing “key” as equally secret.

Preserve supportability

Keep mapping files, symbols and the exact release artifact in controlled storage. Without them, a production crash can become difficult to diagnose. A protection measure that leaves the team unable to support the app is incomplete.

Test serialization, reflection, JNI and third-party SDK initialization after optimization. Excessively broad keeps reduce protection; overly narrow rules can break legitimate functionality.

Inspect without overclaiming

APKLint can surface obfuscation-related signals and potentially exposed configuration. It cannot certify that reverse engineering is impossible or that no credential is recoverable.

A useful review ends with specific changes: remove a privileged key, narrow a keep rule, verify crash retracing or add server-side checks. A single “obfuscated” label is not an actionable security assessment.