1038534 - ClassNotFoundException during XML layout inflation.

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Search Activity, defect)

Description

[Eric Edens [:eedens]]

Attachment: Stack trace

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. [1]

The xml layout was previously modified in bug 1033686.

[1] https://lxr.mozilla.org/mozilla-central/source/mobile/android/search/res/layout/search_activity_main.xml

Comment 1

[Eric Edens [:eedens]]

Attachment: bug-1038534.patch

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 2

[Chris Kitching [:ckitching]]

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 :/

Comment 3

[Nick Alexander :nalexander [he/him]]

What ckitching wrote is https://bugzilla.mozilla.org/attachment.cgi?id=8455690.  Landing.

Comment 4

[Nick Alexander :nalexander [he/him]]

https://hg.mozilla.org/integration/fx-team/rev/3ef49ed42cad

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3ef49ed42cad