Obfuscation shouldn't cause verifying errors (which is what the OP was reporting), it should cause ClassNotFoundExceptions and related stuff.
Yeah, it's a good idea to leave R completely untouched. That includes R $string, R$drawable, R$id, etc. etc. There are things look at that those via reflection, so the names matter, and there's no significant bytecodes to optimize anyway. But I would definitely NOT say you should avoid obfuscation -- though you should consider that option. If you use it, you do have to understand it. But you also have to understand the same issues for shrinking. You have to enumerate all the "seeds" from which its analysis needs to start. This includes every class name in AndroidManifest.xml and the public methods that the framework calls on those classes. But those methods should be protected already because they're coming from base classes in android.jar, which you should be telling Proguard to use as a library. So it should be enough to just protect those class names from obfuscation, plus any custom views you reference from layouts, and similar issues. I may take a crack at coming up with an XSLT script to generate the Proguard script -- assuming I decide it's worth the trouble. What sort of reductions in size are people seeing in practice in Android? Obfuscation to protect against reverse engineering is clearly NOT worth it to me at the price point of the typical Marketplace app! If you do obfuscate, be sure to produce and preserve the mapping files so you can interpret stack traces. On Feb 11, 3:10 am, Daniel Drozdzewski <[email protected]> wrote: > Hey there, > > I am beginning with Android, but have some proguard experience, so > here is what I think: > > You can use optimisations and shrinking as much as you like, but avoid > obfuscation. > Just think, how many classes in your code are referenced using their > names in AndroidManifest.xml. Proguard will happily rename those and > overload agressively, but your manifest XML file remains untouched. > All classes that are mentioned in the manifest file MUST remain > unobfuscated. > > This is just a theory, but you could test it, by adding '- > dontobfuscate' into your proguard settings and checking the effects. > By default the obfuscation is ON. > > Please let the list know about your findings. > > Daniel > > Make sure that your Proguard config ALWAYS, NO MATTER WHAT doesn't > touch R.class for any of its work. > > On 11 Feb, 02:35, sdphil <[email protected]> wrote: > > > > > trying to integrate proguard into my android project. seems to > > generate a binary, but when I go to run that binary on the device, I > > get -- > > > 02-10 18:31:52.219: INFO/Test(10604): gui.StartScreen.clean shutdown: > > true > > 02-10 18:31:52.229: INFO/Test(10604): gui.StartScreen.intent: false > > 02-10 18:31:52.229: WARN/dalvikvm(10604): VFY: copyRes1 v0<-v7 cat=3 > > type=2 > > 02-10 18:31:52.229: WARN/dalvikvm(10604): VFY: rejecting opcode 0x0c > > at 0x0045 > > 02-10 18:31:52.229: WARN/dalvikvm(10604): VFY: rejected Lgl;.a > > (Landroid/content/Context;Ljava/lang/String;)Landroid/graphics/Bitmap; > > 02-10 18:31:52.229: WARN/dalvikvm(10604): Verifier rejected class Lgl; > > 02-10 18:31:52.229: DEBUG/AndroidRuntime(10604): Shutting down VM > > > It starts up with a black screen and then just seems to hang - finally > > comes up with "Force Close / Wait" dialog (ANR). > > > It almost seems like it can't get at the resources?? > > > I'm a bit at a loss about what to do... > > > ideas? > > > tia. > > > p.s. please don't respond with the "merits" of using proguard or not... -- You received this message because you are subscribed to the Google Groups "Android Developers" 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-developers?hl=en
