I think for most of us it is just the idea of going from a familiar, known setup to something new with potential pitfalls that could potentially cause delay in releasing apps initially. I personally look forward to trying the build with Ant as I like to customize things, however, it seems that everyone (including myself) love just hitting the "Easy Button" sometimes.
On Fri, Sep 24, 2010 at 8:05 AM, Xavier Ducrohet <x...@android.com> wrote: > 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<android-developers%2bunsubscr...@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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
