Obfuscation is supposed to make reverse engineering harder. It renames classes and methods and it can remove unused code. Many developers enable it and assume that the job is done. That assumption is risky. A build can pass with obfuscation turned on while the important code stays easy to read.
The mistakes in this guide are common and they are easy to miss in a normal review. A keep rule can expose a whole package. A debug flag can leave extra information in the build. A library can ship with its own symbols intact. Each mistake on its own may look small. Together they can undo the protection that you intended to add.
This guide focuses on your own apps and your own builds. Use it to audit code that you own and to improve your release process. Do not use it to strip protection from apps that belong to other people. The aim is stronger defence for legitimate developers.
Mistake one and two keep rules and debug leftovers
Broad keep rules are the most common problem. A rule that keeps a full package for reflection or for a library can keep names that you meant to hide. Review every keep rule in your configuration and ask why it exists. A rule for a serialisation library may need to keep field names. That rule does not need to keep every class in your app. Narrow the rule to the exact classes that need it.
Debug leftovers form the second problem. A release build should not carry debug symbols or verbose logging that reveals internal logic. Check your build type settings and confirm that debuggable is false for release. Search the release output for log statements that print tokens or internal state. Remove those statements or guard them so they never reach a release build.
Mistake three four and five libraries mapping and testing
Libraries can defeat obfuscation when they are added without review. A library may include its own mapping information or readable names. A library may also require keep rules that expose your interfaces. Check each new dependency and note what it requires. If a library needs a broad keep rule then consider an alternative or isolate the library behind a narrow interface.
Mapping files are a fourth risk. A mapping file lets you read a crash report. That same file also lets someone else restore original names if it leaks. Store mapping files in a safe place and restrict access to them. Never commit a release mapping file to a public repository. Treat it with the same care that you give to a signing key.
The fifth mistake is to never test the result. Build the release APK and inspect it with tools that you own for your own app. Look for class names and string values that should not be visible. A short inspection after each release catches regressions early. Make that inspection part of your release checklist rather than an occasional task.
- Review every keep rule and narrow it to exact classes.
- Confirm that release builds are not debuggable.
- Store mapping files in a safe private location.
- Inspect each release APK before you publish it.
How R8 and ProGuard differ in practice
R8 is the default shrinker in modern Android builds. ProGuard is the older tool that many guides still mention. R8 works faster and it understands newer Kotlin features better. ProGuard rules still work in R8 in most cases but some edge cases behave differently. Test a migration on a copy of your project before you change the main branch. Compare the release APK size and the crash report readability after the change.
Shrinking and obfuscation are two separate steps even though one tool does both. Shrinking removes unused code and resources. Obfuscation renames the code that remains. A project can shrink well and still expose names if keep rules are too broad. Check both outcomes separately. Check size after shrinking and check names after obfuscation. That separation makes a fault easier to locate.
Resource shrinking adds a third check. Unused images and strings can reveal feature names and partner names even when code names are hidden. Enable resource shrinking for release builds and review the list of removed resources in the build report. A resource name that survives shrinking may still tell a reviewer what a hidden feature does. Rename sensitive resources to neutral names before release.
A release checklist that actually gets used
A checklist only helps when it fits into the release flow. Put the checks into the same script or the same document that the release team already uses. Add a step to list keep rules and a step to confirm that debuggable is false. Add a step to inspect the release APK and a step to store the mapping file safely. Keep the list short so a busy team still follows it.
Assign one person to own the checklist for each release. That person does not need to do every check alone. They need to confirm that each check happened and that the result was recorded. A shared note with the date and the build number and the inspector name creates accountability without heavy process. It also makes an audit much easier later.
Review the checklist after a real incident. If a name leaked in a release then ask which check should have caught it. Fix that check rather than adding five new checks that no one will read. A short checklist that improves after each incident beats a long checklist that everyone ignores.
Code you can adapt
# R8 rules that keep only what a serialisation model truly needs
-keepclassmembers class com.example.app.model.UserProfile {
java.lang.String name;
java.lang.String email;
}
-dontwarn com.example.app.model.**The snippet above is an original example written for this guide. It shows a narrow keep rule that protects model fields without keeping a whole package by name.
A narrow rule like this one still allows serialisation to work. It does not give away the rest of the codebase. When you add a new model class you add a narrow rule for that class only. That habit keeps the obfuscation benefit as the app grows.
Testing also matters for string values. Obfuscation renames code but it does not hide every string by default. API endpoints and error messages may remain readable in the APK. Review sensitive strings separately and move secrets out of the app entirely. A secret in client code is not safe even with strong obfuscation.
How this topic connects to nearby work
The techniques that attackers use against weak protection are surveyed in the guide to APK modding techniques for research.
A broader audit routine that includes obfuscation checks appears in the guide to application security audits.
Secrets that obfuscation cannot protect belong in the approach described in the guide to encrypted local storage using Android Keystore.
Putting it into practice
String protection needs a separate discussion because obfuscation alone does not hide strings. API host names and error messages and feature flags often remain readable in a release APK. Review string resources and code constants for sensitive values before release. Move real secrets to a server and keep only public identifiers in the app. A string audit takes an hour for a medium app and it prevents a common source of leakage that name obfuscation cannot fix.
A continuous integration gate can enforce obfuscation checks without extra manual work. Add a build step that inspects the release APK for forbidden class names and for debug flags. Fail the build when a forbidden name appears. That gate catches a broad keep rule that a developer added in a hurry. It also teaches new team members that obfuscation is a release requirement rather than an optional extra. Keep the gate list short so it stays useful and does not block legitimate changes.
A final obfuscation check should run on the exact APK that will be published rather than on an earlier test build. Test builds often differ in keep rules and in debug flags. A check on a test build can pass while the release build still leaks a name. Copy the release APK to a separate folder and inspect that copy with your chosen tools. Record the inspection date and the build version beside the result. That record proves that the published file itself was checked and not just a similar file from an earlier stage.
Common mistakes
A common mistake is to copy keep rules from an example without reading them. Example rules often use wildcards that keep far more than your app needs. Read each rule and test what happens when you remove it. If the app still works then the rule was not needed.
Another mistake is to treat obfuscation as a substitute for real security. Obfuscation slows down reading code. It does not make a secret safe and it does not fix a weak server check. Keep server side checks strong and keep sensitive logic on the server where it belongs.
A third mistake is to ship the same build to every tester and to production without a final check. A tester build may carry extra logging or a debug flag. Label builds clearly and run the release inspection on the exact file that you plan to publish.
Frequently asked questions
Does obfuscation make my app impossible to reverse engineer?
No. Obfuscation raises the effort needed to read code. A determined reviewer can still understand behaviour through testing and analysis. Use obfuscation as one layer among several layers and keep server checks strong.
Should I keep all model classes for serialisation?
Keep only the fields that serialisation needs. A broad keep rule for a whole package exposes more than necessary. Test each narrow rule with real data before release so a missing field does not break the app.
What should I do with a leaked mapping file?
Treat a leak as a serious incident. Rotate any exposed secrets and rebuild with a fresh mapping. Review who had access to the file and tighten that access. Do not publish the mapping file again in a public place.
Conclusion
Strong obfuscation comes from small disciplined choices. Narrow keep rules and clean release builds and private mapping files and a final inspection all work together. No single setting fixes the problem on its own. A checklist that you follow for every release keeps those choices consistent.
Your concrete next step is to open your current R8 configuration today and list every keep rule with a reason beside it. Remove any rule that has no clear reason and rebuild the release APK. Inspect that build before your next publication.
