The point of proguard is to rename classes and methods from DescriptiveClassName.descriptiveFunctionName() to something that's harder to understand intuitively like a.a(). It will not stop de-compilation, just attempt to remove as much context as possible. The main problem with using it in Android is that (AFAIK) you cannot use it to obfuscate things that appear in the AndroidManifest (Activities, Services, Receivers) nor can you obfuscate lifecycle methods like onCreate, onResume, onPause, etc. Since this is traditionally where the bulk of an Android app's code lives, you have to explicitly move all of your logic to helper classes so they can be obfuscated, or come up with your own custom obfuscation before it is run through proguard.
On Wed, Sep 5, 2012 at 12:09 AM, Winnie Zhang <[email protected]> wrote: > Proguard useless. After decompile, all code show up normally. Even binary > java class file, will be in plain text as well. > > [image: AfterProgardScreenCapture] > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/android-security-discuss/-/8jP58Bk4n28J. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > -- Matthew Case Senior Engineer Mobile Defense Phone: 216-375-9438 Skype: matthewcase.md -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
