[insert lengthy and passionate "+1/me too" implementation] Also: > there are much more complicated optimizations to the byte code that Dalvik doesn't handle well.
I'd like to know more about that as well! On Dec 7, 6:34 pm, Matt Quigley <[email protected]> wrote: > In the latest Android SDK Tools (revision 8), ProGuard has been > integrated into the ant build. This is easier to set up than it was > before (http://www.androidengineer.com/2010/07/optimizing-obfuscating- > and-shrinking.html), but I'm curious about the optimizations that are > disabled by default. > > From the proguard.cfg file created with "android update project -p .": > -optimizations !code/simplification/arithmetic,!field/*,!class/merging/ > * > > #1: code/simplification/arithmetic: This removes things like turning > "3 + 3" into "6". A shame, but understandable, because there are much > more complicated optimizations to the byte code that Dalvik doesn't > handle well. This one is completely understood. > > #2: !field/*: This refers to the following: > field/removal/writeonly - Removes write-only fields. > field/marking/private - Marks fields as private, whenever possible. > field/propagation/value - Propagates the values of fields across > methods. > > #3: !class/merging/*: This disables merging two or more classes > horizontally or vertically (in the same class hierarchy). > > The question here is, why would #2 and #3 give Android or Dalvik any > problems? The classes are valid Java classes in the end. I suspect > the answer for #2 is that projects built into Android require that the > R.* classes to remain intact. However, this is NOT the case for > private apps created by developers, unless they use introspection to > access those fields. There is no need for the R class at all; all of > the constants of that class can be propagated into whomever uses them, > and the the R class can be removed. For #3, this might have something > to do with the fact that Views referenced in layout .xml files are > dynamically created at runtime by reflection, and maybe merging these > classes together messes them up. But isn't that prevented by -keep > public class * extends **View? > > For over a year I've been obfuscating my app and #2 and #3 have never > been used. I don't plan on using them from now on, either. Unless, > someone can clarify why I shouldn't be enabling #2 and #3? > > Thanks! > -Matt > > P.S. I would recommend adding the following to the next version of the > Android SDK Tool's automatically generated proguard.cfg file: > # Keep classes which are not directly referenced by code, but > referenced by layout files. > -keep public class * extends **View { > public <init>(android.content.Context); > public <init>(android.content.Context, android.util.AttributeSet); > public <init>(android.content.Context, android.util.AttributeSet, > int); > public void set*(...);} > > This prevents classes which extend View, TextView, etc. classes from > being renamed. This will avoid ClassNotFoundExceptions when > developers use custom View classes referenced in their layout files. > It will hit some false positives (i.e. a class which ends with View > may not actually be used as such), but that is acceptable IMHO, and > can be easily changed by a developer as needed. > > An alternative is to use -keep public class * extends > android.view.View, which removes all false positives, but will add > some missed cases, such as a class which extends TextView. -- 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
