September 21, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Configuring ProGuard to Protect Your Android Applications, Page 2

  • February 24, 2011
  • By Lauren Darcey & Shane Conder
  • Send Email »
  • More Articles »

Configuring ProGuard for Your Android Applications

The reasons for using ProGuard are so compelling that the Android Development Tools plug-in for Eclipse (ADT) added automatic ProGuard support in ADT 8.0.0, which also includes everything needed for using ProGuard with Android. When you create a new Android application in Eclipse, the root of the project will contain a proguard.cfg file that provides the starting point for configuring ProGuard to run on release builds of your application. This alone, though, does not enable ProGuard for your application.

To enable ProGuard for you application, place the following line inside the default.properties file:

proguard.config=proguard.cfg

This setting will turn on ProGuard processing when you export a signed or unsigned APK file using the Android tools menu. Besides the added protection of obfuscation, a recent package file we used ProGuard on shrunk from 678KB to 518KB -- a savings of nearly 25%. Surely users will appreciate the faster downloads and more free space on their devices.

Note: Don't worry about the comments in the default.properties file that warn against modifying the file. The file will be modified, but in our experience, the config values we add, such as proguard.config, will remain untouched.

Dealing with Error Reports After Obfuscation

Now that your Android application source code is obfuscated, your error reports will also be obfuscated. Luckily, the ProGuard tool outputs a file named mapping.txt that later can be used to de-obfuscate the error report. Within the SDK tools directory, there is a directory name called /proguard. In that directory, you'll find a tool called retrace. This tool will take an obfuscated stack trace and make it readable again. The mapping.txt file is stored in a directory named proguard, found in the root of your project.

There's one important caveat, though. Every time you make a release the mapping.txt file is recreated. It's not necessarily the same every time. This means that each time you actually release an application to users, you'll need to keep the mapping.txt file and keep which release it goes with. Otherwise, stack traces will be basically useless to you.

Common ProGuard Problems and Solutions

While the default ProGuard configuration file created by the ADT plug-in works reasonable well for many Android applications, you can sometimes run into snags. The techniques that ProGuard uses to modify your source code can lead to some problems either during the ProGuard modification or on the released file. Some common problems and error messages include:

  1. External libraries referencing other libraries you don't use -- usually results in many warnings, such as "can't find dynamically referenced class"
  2. Paths with spaces -- usually results in the warning "'C:Program' is not recognized as an internal or external command"
  3. Crashes (aka "Force Close") when using onClick properties in layout files

The first error can be caused by external libraries that conditionally include other libraries that you don't use. A viable solution is usually to add a specific configuration value to not warn about each instance. You'll need to test carefully to make sure you actually aren't using the reference class. The following setting within the proguard.cfg file should suffice:

-dontwarn com.package.classname.**

The second error results from pathnames that contain spaces. This generally results from one of the tools you use being in a path that contains spaces. You either need to reinstall any tools that contain spaces, or look into alternate solutions. See this Stack Overflow page for more details.

Finally, the third error is caused by both the use of reflection and the only reference to the call being from the layout files. To solve this problem for all such click handlers, place the following in your proguard.cfg file:

-keepclassmembers class * {
  public void *(android.view.View);
}

This tells ProGuard to keep any method call in any class that takes a single View object parameter. This may be over-aggressive, but it is simple, easy to maintain, proven for our own applications, and hasn't increased the size of the resulting package appreciably.

For other problems, we recommend checking the documentation for ProGuard or searching in Android support forums.

Conclusion

ProGuard is a useful tool for protecting your Android applications as well as making them smaller and more efficient. Enabling ProGuard is now very simple within Eclipse with the ADT plug-in. However, you must be aware that it changes the code inside the packages and may have implications in your application. Therefore, be sure to thoroughly test the release version of your application prior to release. For Android developers, there's little excuse not to provide at least this moderate level of protection to your application source code.

About the Authors

Shane Conder Shane Conder and Lauren Darcey -- Contributing Editors, Mobile Development -- have coauthored two books on Android development: an in-depth programming book entitled Android Wireless Application Development (ISBN-13: 978-0-321-62709-4) and Sams Teach Yourself Android Application Development in 24 Hours (ISBN-13: 978-0-321-67335-0). When not writing, they spend their time developing mobile software at their company and providing consulting services.

         Email          |          Blog          |          Twitter          

Lauren Darcey

Tags: Android, obfuscation

Originally published on http://www.developer.com.

Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel