Protecting Your Android Applications
- Obfuscation with ProGuard
- Using the License Verification Library
- Using SSL for Network Communication
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Once published, Android applications—and their developers—face numerous threats to success in the real world. One Android developer advocate at Google recently referred to these pesky perpetrators as pirates (outright thieves) and vampires (those hangers-on sucking the life out of your product). A paid application might be stolen, illegally copied, and made available for download in alternative locations. A free application might be exploited, causing damage to a brand and leveraging valuable product resources like server bandwidth. All apps are vulnerable to hacking, resulting in rogue downloads with embedded malware, or using knowledge learned to hack a server or other underlying service. Unfortunately, this malicious behavior happens all the time. Protecting your applications is an ongoing battle, one that cannot ever truly be “won” because the opposition is constantly improving its nefarious methods of attack. You’ll never have a truly invulnerable app, but you can make your app a hard target.
The good news is that, as Android developers, you have numerous ways to help protect your Android applications from exploitation. Today you will learn how to:
- Obfuscate your binary code using ProGuard
- Use the License Verification Library to verify Android Market purchased applications
- Protect your network communications with SSL
Obfuscation with ProGuard
ProGuard is an open-source tool for compacting and obfuscating compiled Java code. From a protection point of view, the resulting binary files are much harder, but not impossible, to reverse-engineer. Using ProGuard to protect your Android apps within Eclipse is quite easy. In fact, new Android projects created with the Eclipse wizard for new Android applications now include a default ProGuard configuration file, proguard.cfg. Although this configuration file is created automatically, ProGuard is disabled by default. This is by design, because the configuration file will not work for all applications.
To enable ProGuard, add the following configuration line to the default.properties file:
proguard.config=proguard.cfg
Now ProGuard is enabled, but only when you use the Android Tools to export a signed or unsigned package—that is, a release mode build, not a debug build. Obfuscation of debug builds would simply make it much harder to debug your own code.
Finally, there are several very common situations where the default configuration file doesn't work. Let’s look at some common issues that arise when you first begin using ProGuard. During the export process, ProGuard may display some errors. One common error looks a lot like this:
[2011-05-31 16:52:07 - HoneycombFragments] Warning: android.support.v4.app.ActivityCompatHoneycomb: can't find referenced method 'void invalidateOptionsMenu()' in class android.app.Activity [2011-05-31 16:52:07 - HoneycombFragments] Warning: android.support.v4.app.ActivityCompatHoneycomb: can't find referenced method 'void dump(java.lang.String,java.io.FileDescriptor, java.io.PrintWriter,java.lang.String[])' in class android.app.Activity [2011-05-31 16:52:07 - HoneycombFragments] Warning: android.support.v4.view.MenuCompatHoneycomb: can't find referenced method 'void setShowAsAction(int)' in class android.view.MenuItem
The error messages go on to talk about how the classes are inconsistent. This may happen when you try to use ProGuard on a project using the Android compatibility library. The warnings, all of which end in CompatHoneycomb, are for compatibility classes that are used to call the Honeycomb versions of methods. This only happens when they are available. When your project targets older SDK versions, as it often does when working with the compatibility library, these warnings can be safely ignored by adding the following warning suppression line to your ProGuard configuration file (proguard.cfg):
-dontwarn **CompatHoneycomb
Then, in a manner similar to the existing -keep statements that exist in the file by default, you'll want to include classes that you use. For instance, if you're using fragments, you'd want to add this line:
-keep public class * extends android.support.v4.app.Fragment
This will keep around any unreferenced class that extends Fragment. If you've only referenced your fragments through XML, this is absolutely required.
This brings up another common issue: having the handlers for the onClick XML property stripped. One method of handling button clicks is to set the android:onClick property to the name of a method that will handle the click within the Activity class. Because ProGuard does not see any references to the method as it does not read the XML resource files, it simply strips the methods thinking they are not used. This problem, too, has an easy solution:
-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}
This configuration tells ProGuard to keep any class member methods for classes that extend from Activity and that return void and take a View object as a parameter. This exactly matches the handler methods for the onClick XML property.
Once you have edited the proguard.cfg file to suit your project, you're ready to test your application thoroughly. Going through the trouble will help protect your application from tampering and reverse-engineering, regardless of your distribution method.
For more information on ProGuard and how to configure it, visit the ProGuard website.
For more information on using ProGuard with Android, refer to the Android Guide.