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
