Neat idea. An annotation wouldn't work for things in JAR libraries, however. Back when I tested ProGuard to see if it helped my frame rates, I had to turn obfuscation off for some classes in JARs I use.
Not sure why, maybe the library used reflection or something. It wasn't even a weird library, just one of the metrics or ads ones that lots of people use. The most powerful solution would be to just have a file field in the project properties for a ProGuard config file to use. I guess since people are complaining they can't use Ant, maybe they would complain they can't edit config files on their own too, however. On Sep 25, 5: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
