ProGuard has great documentation. Click on the Manual link on the left at their site: http://proguard.sourceforge.net/
They even have an example configuration file for Android projects in the Examples section. It was there a long time before this recent change by Google to add ProGuard support to the official Android build files as well. I did all my testing with ProGuard back then and had very little problems. I really can't agree that this is lacking documentation. On Sep 26, 2:55 am, Indicator Veritatis <[email protected]> wrote: > Google people should stop telling people to "go read the source" or > "go read the config file", when others ask for what Google should have > documented. > > On Sep 25, 7:15 am, Xavier Ducrohet <[email protected]> wrote: > > > People should read the blog post Dan posted and read the files that > > comes with it. > > > one of those files is the Ant additional rules, the other one is a > > proguard config file. > > > In this file, there are rules to not obfuscate the activity, service, > > broadcastreceiver, etc... classes. > > For the native method, it's not if the name contain native, it's if > > the method *is* native. > > (there are more rules in there, go look at it) > > > This file is placed in your project folder and the Ant rules calls > > proguard with it. > > You are free to add any rules you might see fit. > > > It's a lot better than the tools doing some sort of static analysis on > > your code and hoping we catch all the cases where your code shouldn't > > be obfuscated. > > > Using an annotation would work, but we'd have to look at all your code > > (making the build slower), and wouldn't work if you reusing someone > > else's code who didn't think about it. Managing a simple text file is > > how proguard already does it, and it's more lightweight to simply edit > > that file than going to look for annotation in your code. > > > Xav > > > On Sat, Sep 25, 2010 at 2:40 AM, Indicator Veritatis <[email protected]> > > wrote: > > > That is excellent information. Thank you for posting it. > > > > But there is one thing that surprises me as it is written, so I must > > > ask for clarification: when you say, "there is no way we can figure it > > > out programmatically[sic], do you mean that such is the case even when > > > Proguard is integrated with ADT? Surely you can at least do most of > > > them by identifying classes needed by AndroidManifest.xml by simply > > > reading AndroidManifest.xml. Or are there many other classes that also > > > need to be protected? From reading Dan's post, it seems the former > > > were the main examples of classes that need to be protected. > > > > BTW: using the native method name as the name of the class sounds like > > > it should be discouraged: obfuscation difficulties just might be > > > discouragement enough;) > > > > I am not sure what you mean by "anything which has a constructor > > > similar to a View", but it SOUNDS like you could introduce a decorator > > > to simplify handling all of these special cases. "@no_obsfucation" is > > > the name that occurs to me, but I am sure you can do better. > > > > On Sep 24, 6:00 am, Xavier Ducrohet <[email protected]> wrote: > > >> We are working on direct support in ADT/Ant. We just decided to > > >> release a quick blog post on how to manually add this to Ant since > > >> it's somewhat easy to do (unlike ADT). > > > >> However, proguard does need to know about which class to not obfuscate > > >> and there is no way we can figure it out programmatically. Proguard > > >> itself does try to detect reflection usage, but if it's too dynamic > > >> (for instance the class/method/field to use by reflection is dynamic > > >> and too complex to see where the value is coming from) it will fail. > > > >> The proguard config file shown in the Dan's blog post (a different Dan > > >> btw) provides exclusion for the common cases: > > >> - anything that extends Activity, Service, Application, > > >> BroadcastReceiver, ContentProvider as those are referenced in the > > >> manifest. > > >> - anything that has native method as the name of the class is used to > > >> find the native function name > > >> - anything that has a constructor similar to a View, to no rename > > >> custom views as their name are referenced in layouts > > > >> This should cover all the default cases. Now, if you do some fancy > > >> reflection you will have some problem, and will have to tell proguard > > >> what to not obfuscate, but there's nothing we can do about and any > > >> obfuscators will have similar problems. > > > >> We are looking at implementing Proguard in ADT/Ant in a way that makes > > >> it easy to plug a different obfuscator, so if you prefer a different > > >> solution you will hopefully be able to use it, but I'm pretty sure > > >> you'll have the same issues. > > > >> Unfortunately I can't give a release date for the next version, but we > > >> usually try to release new tools every 2-3 months. > > > >> Xav > > > >> On Thu, Sep 23, 2010 at 6:50 PM, Indicator Veritatis <[email protected]> > > >> wrote: > > >> > It is not just you. I was pretty disappointed when I read that post, > > >> > too. I did get a kick out of seeing what a menacing appearance Dan has > > >> > with his new beard and moustache, though;) > > > >> > I am amazed that Google seems to think it is acceptable to force the > > >> > user to maintain two different build systems -- one for Eclipse and > > >> > one for the recommended independent installation of Ant -- and also > > >> > maintain a text file with a list of classes not to obfuscate. It is > > >> > too obvious that this is a task ADT should be doing. > > > >> > But rather than run for the hills, we should pepper Google with > > >> > uncomplimentary speculations concerning their motives for this "turd > > >> > layering" until they 'fess up and give us a release date for a version > > >> > of ADT that will allow us to include Proguard in an Eclipse build > > >> > WITHOUT these problems. > > > >> > On Sep 22, 9:59 pm, JP <[email protected]> wrote: > > >> >> Just read the latest Android Developer blog > > >> >> post.http://android-developers.blogspot.com/2010/09/proguard-android-and-l... > > >> >> Quite the beast. And Proguard cannot even be used with confidence > > >> >> ("it’s still possible that in edge cases you’ll end up seeing > > >> >> something like a ClassNotFoundException"). > > > >> >> Is it just me getting irritated where this seems to be going? > > >> >> In my more active days developing, pretty graphic slang was applies to > > >> >> efforts like this: "Turd layering". Meaning: More dependencies, more > > >> >> procedure, more sources of error, and it doesn't even work "right". In > > >> >> of itself, adding innocent looking steps to a release procedure (for > > >> >> some relatively obscure benefit) might be marginally worthwhile, but > > >> >> in the bigger picture, releasing an app increasingly becomes a burden. > > >> >> Dare you miss a step. Or try to teach somebody else how to go through > > >> >> a release and verify it. Or you want to go and rebuild a development > > >> >> environment. Or lose the ominous reference file (mapping.txt)... > > > >> >> Anybody care to disagree and convince me this all nice and dandy and > > >> >> we don't have to literally run for the hills? > > > >> > -- > > >> > 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 > > > >> -- > > >> Xavier Ducrohet > > >> Android SDK Tech Lead > > >> Google Inc. > > > >> Please do not send me questions directly. Thanks! > > > > -- > > > 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 > > > -- > > Xavier Ducrohet > > Android SDK Tech Lead > > Google Inc. > > > Please do not send me questions directly. Thanks! -- 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
