(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
