Thank you so much Xavier! 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
