This is not a trend. People should use proguard. Many people don't know how, so we made a blog post to help them. Using LVL really benefit from proguard, so we feel it was important enough to do it before we had full proguard support in the tools.
But even with proguard support in the tools you will likely have to tweak the proguard config file. There's no way around this. Honestly, if a developer is too lazy to learn how to use proguard then he/she shouldn't use it. There are very few things in development when you can press a button and have it do the right thing without having to configure anything. On Mon, Sep 27, 2010 at 12:33 AM, Indicator Veritatis <mej1...@yahoo.com> wrote: > You are refuting a straw man argument. If the documentation is so good > at the Proguard site, then Google's documentation, in particular in > Dan's blog, should have referred to it. It also should have been > written to complement the Proguard documentation, not as it to replace > it. But neither happened. > > This is a flaw in Google's approach, no matter how you spin it. It > would not be a very serious flaw, if it were not covering up yet > another flaw: one of the great promises of the ADT in Eclipse from > early on was to shield the developer from having to use, or even learn > Ant except for esoteric tasks. But now that Google is recommending > Proguard as a standard practice, ADT no longer does this: now we have > to use Ant. > > This is a bad trend. It is the same bad trend that inspired the > invention of the computer language forth years ago, the bad trend of > requiring a programmer to know several languages just to get one thing > done. > > Now I know that many will object, saying something like, "but Ant is > so much part of the culture now, everybody should know it". But look > at how many people are already trying to replace it with Maven (http:// > java.dzone.com/news/maven-or-ant, > http://www.webforefront.com/archives/2009/09/java_build_tool.html). > In a few weeks, who knows what other XML based language will pop up > trying to replace both? Apache is already trying to replace Maven with > Ivy! > > On Sep 26, 3:11 am, Lance Nanek <lna...@gmail.com> wrote: >> 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 <mej1...@yahoo.com> 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 <x...@android.com> 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 <mej1...@yahoo.com> >> > > 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 <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! >> >> > > > -- >> > > > 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! >> >> > > -- > 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! -- 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
