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
| Transformation | Intended effect | Limitation |
|---|---|---|
| Shrinking | Remove unused code | Dynamic use may need rules |
| Optimization | Simplify or restructure code | Requires release testing |
| Obfuscation | Rename or obscure symbols | Does not encrypt all behavior |
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.
Review a recoverable endpoint and a privileged credential differently
Consider an app containing a public API hostname and a private administrative token. Renaming the networking class does not make the token suitable for distribution. The hostname may be necessary public configuration, whereas the administrative token lets its holder exercise privileges outside the user's authorized session. Remove that privilege from the client design and revoke an exposed credential through the service's supported process.
For a proprietary calculation implemented locally, obfuscation can make casual reading harder, but a motivated analyst can still observe inputs and outputs or inspect execution. Decide what risk the product can tolerate when the algorithm must run on a device controlled by someone else. Do not advertise the presence of short symbols as proof that the algorithm cannot be studied.
Make the protection review reproducible
Choose one release and record its artifact digest, build-tool version and optimization configuration. Inspect several application-owned classes, public resources and representative strings. Separate evidence of renamed symbols from evidence of removed code or encrypted application data. The R8 optimization guide describes distinct transformations; an inspector's single score cannot establish all of them.
Then exercise a reflective feature and a crash-reporting path on that exact release. A useful protection configuration preserves necessary runtime contracts and supportability. If a serializer relies on stable field names, check its actual wire format before and after optimization. A smaller package that changes a server payload unexpectedly has introduced a compatibility failure.
Record limitations alongside results: which behaviors remain observable, which secrets were removed, which dynamic entry points need keep rules and where diagnostic mappings are stored. Keep those mappings controlled without making them impossible for the incident-response team to retrieve. Revisit old rules when an SDK changes, using the original regression scenario to determine whether each exception remains necessary. This produces a concrete engineering review rather than a promise of unbreakable protection. Artifact inspection supports that review, while authorization, data minimization and credential handling still require examination of the application and its services.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
