Closed Bug 1038534 Opened 6 years ago Closed 6 years ago
Not Found Exception during XML layout inflation .
Search activity builds and executes as a standalone project; it has ClassNotFound exception when built along with Fennec. The referenced class, PostSearchFragment, is not used in Java code -- it is only referenced in an XML layout.  The xml layout was previously modified in bug 1033686.  https://lxr.mozilla.org/mozilla-central/source/mobile/android/search/res/layout/search_activity_main.xml
Theory: Since the classes are only referenced from the XML layout files, proguard is removing them. This patch to the proguard conf removes the ClassNotFound exception.
Comment on attachment 8455917 [details] [diff] [review] bug-1038534.patch Review of attachment 8455917 [details] [diff] [review]: ----------------------------------------------------------------- Yup, looks like Proguard. (You might want to use the MOZ_DISABLE_PROGUARD build flag to make absolutely 100% certain nothing completely bonkers has happened). ::: mobile/android/config/proguard.cfg @@ +196,5 @@ > > -keep class **.R$* > > +# Keep classes that extend support fragments. > +-keep public class * extends android.support.v4.** I don't think this does what I think you think this does. What this says is "Keep every class that either is or extends anything in the package android.support.v4". That doesn't match the comment which suggests this should only be keeping Fragments. What you'll probably want, then, is something nearer to: -keep public class * extends android.support.v4.app.Fragment Which should solve your current problem without dragging the entirety of the support library (including the stuff we're not using) with it. Depending on how Fragments are used internally, you may also need to explicitly keep some *members* of the class (see other lines in the configuration file for a few places where we do this to keep Proguard from deleting parts of Views that are only called into by the system, for example). The goal, naturally, is to minimise the amount of stuff we include. The support library is extremely large, so we only want to keep the small parts of it we're using and throw away the rest of it. (Googling seems to suggest the approach others have taken in the face of this problem has been to just "keep *all* the support library things". Hopefully we can do better...) But, yes, your general idea seems correct! Proguard's configuration format is quite obtuse :/
Attachment #8455917 - Flags: feedback?(chriskitching) → feedback-
What ckitching wrote is https://bugzilla.mozilla.org/attachment.cgi?id=8455690. Landing.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 33
You need to log in before you can comment on or make changes to this bug.