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
(Pushing to a CLOSED TREE because this is Android only.)
The preprocessed files, all of which are constant exports, are exposed
in the new constants JAR.
--HG--
extra : source : 05cf424592e66f30c9a6c92f07bb5d9cdf1595a6
extra : amend_source : fda465d3aa6ed282bfa2b9542358ffd1cf2d1177
I replaced the compile-time ANDROID_PACKAGE_NAME with the run-time
context.getPackageName() for two reasons:
1) I claim this is more correct. It's hard to imagine Fennec working
with ANDROID_PACKAGE_NAME != context.getPackageName(), but right here
we should use the run-time, not the build-time state.
2) GeckoLoader is part of GeckoView, and as such it shouldn't assume
anything about the package it's running as.
GeckoView consumers may ship for multiple architectures, so we
shouldn't assume anything about the build-time architecture, but the
reference to MOZ_CPU_ABI is purely diagnostic. There are substantive
changes to make here; we'll cross that bridge some other time.
--HG--
extra : source : 48fc328377d41596900fa924b21378ba65a0df1f
The constants JAR contains AppConstants and SysInfo. SysInfo depended
on HardwareUtils for one function, which can (should?) be in SysInfo
anyway, so I moved it.
Both SysInfo and AppConstants should be available to Robocop tests,
but they are compiled too early to access RobocopTarget. Since
nothing in GeckoView should know about GeckoView, I moved the
annotation to the Fennec-level proguard.cfg.
--HG--
extra : source : d2c14599cbab6c476465a6ba142c7c2501895cb3
I am thrilled that we no longer generate any Java files with "package
@ANDROID_PACKAGE_NAME@;". Progress, a little at a time!
--HG--
extra : source : fa85f8d8b182fad743556a012a982daad121f0b1
This lands the widget/Themed*.java sources into the tree and provides
a simple script for regenerating them in the source tree. Use it
like:
<edit mobile/android/base/widget/ThemedView.java.frag>
$ ./mach python mobile/android/base/widget/generate_themed_views.py
$ hg diff
... changes to Themed*java
--HG--
extra : source : 4bcc69eb4a27db09b2423c52c22a0c07baffd7d0
The preprocessed files, all of which are constant exports, are exposed
in the new constants JAR.
--HG--
extra : rebase_source : f82988bd98e2390889057982d322add509b2d1c9
extra : source : 05cf424592e66f30c9a6c92f07bb5d9cdf1595a6
I replaced the compile-time ANDROID_PACKAGE_NAME with the run-time
context.getPackageName() for two reasons:
1) I claim this is more correct. It's hard to imagine Fennec working
with ANDROID_PACKAGE_NAME != context.getPackageName(), but right here
we should use the run-time, not the build-time state.
2) GeckoLoader is part of GeckoView, and as such it shouldn't assume
anything about the package it's running as.
GeckoView consumers may ship for multiple architectures, so we
shouldn't assume anything about the build-time architecture, but the
reference to MOZ_CPU_ABI is purely diagnostic. There are substantive
changes to make here; we'll cross that bridge some other time.
--HG--
extra : rebase_source : 65b374746f1630fd7c7c201a50bc2ff9dd29090d
extra : source : 48fc328377d41596900fa924b21378ba65a0df1f
The constants JAR contains AppConstants and SysInfo. SysInfo depended
on HardwareUtils for one function, which can (should?) be in SysInfo
anyway, so I moved it.
Both SysInfo and AppConstants should be available to Robocop tests,
but they are compiled too early to access RobocopTarget. Since
nothing in GeckoView should know about GeckoView, I moved the
annotation to the Fennec-level proguard.cfg.
--HG--
extra : rebase_source : cdba5f056a41ec28f190dd7ebf82213a358cb3a8
extra : source : d2c14599cbab6c476465a6ba142c7c2501895cb3
I am thrilled that we no longer generate any Java files with "package
@ANDROID_PACKAGE_NAME@;". Progress, a little at a time!
--HG--
extra : rebase_source : f5211b309488adbab3ad47e63f1a3920093a85d8
extra : source : fa85f8d8b182fad743556a012a982daad121f0b1
This lands the widget/Themed*.java sources into the tree and provides
a simple script for regenerating them in the source tree. Use it
like:
<edit mobile/android/base/widget/ThemedView.java.frag>
$ ./mach python mobile/android/base/widget/generate_themed_views.py
$ hg diff
... changes to Themed*java
--HG--
extra : rebase_source : c32966b91ac0c1c5719532e3b558c123c3d02c7e
extra : source : 4bcc69eb4a27db09b2423c52c22a0c07baffd7d0
I went with gradle instead of gradlew because it's more likely to be
what users consider. And mach helpfully fixes up the uncommon typo.
This is a little hard-coded right now but I don't think it's likely
any other Gradle consumer will arise in the short term.
--HG--
extra : source : 67ce3d7591f944fa458758d97f443651f0e40dac
extra : amend_source : d10846e845deda5d368bdfdbb5b3d68706038992
extra : histedit_source : fb30750f389444a9619778d4c690d7de5e5fcbc1
This ticket splits a new omnijar project off of base. The new
project's omnijar task knows the inputs (well, those under
mobile/android) and the omni.ja output and only re-packages the
omnijar when the task's output is out of date.
With this modification, local building and most importantly the
Android JUnit test cycle is much improved, because the APK is not
re-deployed when only test code is modified.
In addition, the new project lists the omnijar inputs as "Java" source
directories. Previously, they were listed as "Java resource" source
directories, which meant that the omnijar inputs were packaged into
the final APK. This wasted time and space.
--HG--
extra : rebase_source : 12c94fdfbee9b7c319d5cfb4d7faad254e90abfc
