ProGuard

ProGuard is a must. We will never release a version without turning it on.

There are two separate file - the Android defaults (proguard-android-optimize.txt) and our own specific settings.

It helps us greatly in optimizing our code and to secure it better (it obfuscates it).

Do’s:

• Run it on a frequent basis. The sooner you catch the problems that may occur, the easier it will be to fix them.
• Keep it well documented, indicating what part is related to what code section.
• Integrating new 3rd party? Copy his ProGuard configuration to our project.

And Don’t…:

• Do not wait for the day of release to run it. I assure you it will not work. I assure you will spend the night in office trying to fix it :)
• Having the code compiled doesn’t mean it worked. In order to make sure everything works do some smoke tests as well. Usually the ProGuard will break the run-time and not the compile-time.

Reversing the obfuscation

Having obfuscation is great, but what happens when we want to examine a crash report and it’s obfuscated?

For that, we have to keep track of the “mapping.txt” file, for each release.

To keep track of that, we will keep this mapping.txt file inside our git, and on each “release/….” branch we will make sure it is being updated to the latest release.

Testing if it worked

Make sure it worked by opening the APK file and transforming the .class files to .java with the help of JD-GUI app.

The quickest leanest implementation

If all you seek is to hide the code you wrote and optimizing other 3rd party libraries does not interest you, a simple configuration would be to keep everything else that is not in your project package name. For example, If you have external libraries that starts with "org.", you can have: