(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
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
For all applications, MOZ_DATA_REPORTING is set in configure if any of
MOZ_TELEMETRY_REPORTING, MOZ_SERVICES_HEALTHREPORT, or MOZ_CRASHREPORTER
is set. For mobile/android, we *also* set MOZ_DATA_REPORTING when we're
not in a release (Beta/Release) build.
Geo/stumbler data is build-time enabled by MOZ_ANDROID_MLS_STUMBLER but
does not automatically upload data: the user must manually enable
uploading geo/stumbler data. That is, this is an explicit opt-in rather
than an explicit opt-out; and geo/stumbler data should not be covered by
the data reporting notification at this time.
In the past, I believe that geo/stumbler data was uploaded based on the
feature being build time enabled, which corresponded to !RELEASE_BUILD,
so the logic being removed was reasonable.
This has a few important changes:
1) Null-check the TelephonyManager availability.
2) The cell scanning code was split to remove wcdma scanning on Fennec due to an older API level on Fennec. This is no longer the case. CellScannerNoWCDMA.java renamed to CellScannerImplementation.java.
3) Remove broadcastsync on the timer thread, have the timer thread message back to the owning class through a handler (guaranteed thread-safe mechanism to notify the owning class that work is done).
