BTW, I would be interested in hearing the problem people have switching between Ant and ADT.
We are trying to make sure that one can use both at the same time. I think it makes sense to use ADT during development but use Ant for automated builds for instance. I do realize Ant is much more customizable than ADT so going from a heavily customized Ant to ADT might be impossible, but if you use Eclipse it should be relatively easy to compile your project with Ant. For simple project, all you need to do is run the 'android update project' command, and then run "ant debug" or "ant release". If there is something preventing you from doing it, please let me know, as I think we should probably fix this. thanks, Xav On Fri, Sep 24, 2010 at 6:00 AM, Xavier Ducrohet <x...@android.com> 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 <mej1...@yahoo.com> > 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 <joachim.pfeif...@gmail.com> 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 android-developers@googlegroups.com >> To unsubscribe from this group, send email to >> android-developers+unsubscr...@googlegroups.com >> 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! > -- 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
