Any class that has access to a context should call Prefs.getInstance(Context) which is guaranteed to return a Prefs.
With no context, classes can call Prefs.getInstanceWithoutContext() but they must null-check the return, and handle accordingly.
Fortunately, the latter case happens in very few places, all of which require no special handling of this case.
This change:
- maintains context-less access to the Prefs
- classes internal to the service can safely call getInstanceWithoutContext(), as the service (or the MainApp in the stumbler case)
will have instantiated a Prefs so that getInstanceWithoutContext() will return a prefs
- protects against null Prefs if we have failed to consider a particular entry point to the code will require that Prefs was instatiated with a context.
This applies Proguard to third-party libraries such as the Android
support-v4 library and the Google Play Services libraries.
Previously, these were not Proguarded, bloating the Fennec APK.
Technically, this required a few work-arounds, including:
* stripping library debug information with a early Proguard
invocation;
* altering the optimizations tried; and
* reducing the number of Proguard passes.
--HG--
rename : mobile/android/config/proguard.cfg => mobile/android/config/proguard/proguard.cfg
extra : rebase_source : 6d638695b6c8f759578aba5f1eda668fc9c28e9d
extra : amend_source : 96a475c0739c4b44a3df3fdfd2c59321836d9694
Pretty straight-forward implementation of the mock. The mock shows a
different "bookmark star" icon, with slightly different right-margins,
and implementing that change requires changing the TwoLinePageRow layout
to not use drawableRight for the star. (Otherwise, the star will not be
vertically centered in the container.) I don't care to make that change
for this ticket.
In editors (Eclipse and IntelliJ), Android View sub-classes are created
in a "Bridging" mock context. There is no ambient GeckoApplication in
this case. It's already okay for the LWT to be null; let's loosen the
requirement that there be an ambient GeckoApplication to let these View
sub-classes render in editors.
It appears that Classycle is dependent on the version of javac that
compiles the .class files. There are real references between two
sets that are not caught by Classycle; ckitching and I theorize that
Classycle misses a reference from a set if it is a constant that is
inlined by the javac compiler. This inlining differs between javac
compiler version.
--HG--
extra : rebase_source : 9040c77c604c8b76c4bfe1142c7efa015a82dcb5
