This patch lays the groundwork for two things. First, it paves the
way for splitting AppConstants.java into two parts, a GeckoView part
and a Fennec part. This is necessary because the Makefile.in
preprocessing is not flexible enough to write two separate GeckoView
and Fennec constants files into different directories.
Second, this allows us to more flexibly generate the file contents.
Gradle has a way to get compile-time constants into Java code, which
we want to migrate to. The details don't matter right here, but this
paves the way to move from preprocessing to generating the
Gradle-style BuildConfig files while we continue to support both build
systems.
MozReview-Commit-ID: 2o8X99uLoaM
--HG--
extra : rebase_source : 54164d685b9c2b1342b1acba2913ce07b906a7d6
GECKOVIEW_JARS contains two Adjust classes (within constants.jar). These depend on the rest of adjust,
which was previously within FENNEC_JARS. Without the remaining adjust jars being on the classpath during
annotation processing for GECKOVIEW_JARS, we are unable to correctly process those Adjust classes
(i.e. we get a NoClassDefFoundError).
The minimal fix is to process adjust as part of GECKOVIEW_JARS. Because adjust depends on HttpClientLib,
we also need to move the relevant jars into GECKOVIEW_JARS too (sync-thirparty contains HttpClientLib).
This will probably require further untangling, this is a minimal patch to allow beta to actually build.
MozReview-Commit-ID: DLtazTrg3hV
--HG--
extra : rebase_source : ce4ecd7941cb34a9f430ea3da906f7d67775c4d2
This flag seems to no longer be needed, and prevents the use of switch statements for resource ID's. It was first introduced for mach based geckoview builds, however geckoview now seems to be built using gradle which is able to invoke aapt to produce better R.java's, resulting in constant Resource ID's in Fennec.
MozReview-Commit-ID: EjWCX4nvlht
--HG--
extra : rebase_source : 3eb30debbc76c39bd8e367bf8709eaaf1592f42a
This allows us the use of VectorDrawable's (which can be created by converting SVG files) in a
limited set of circumstances.
MozReview-Commit-ID: 4n4dXnZYn9W
--HG--
extra : amend_source : 8fbf2579260590a26ecd0112d6fce1055e929bd7
CLOSED TREE
--HG--
extra : amend_source : 1f0c7bbb5aa8a3dab38f0785e13e32f59e8f8c79
extra : histedit_source : ca99420cac7019a4b6fd6aab781b93151092a8bc%2C0ef091317a27688c734f20417875406726e35de7
Separate compiled JARs into GECKOVIEW_JARS and FENNEC_JARS, and run
AnnotationProcessor separately on each set. The GeckoView bindings are
put into widget/android/GeneratedJNI* (same as before), while the
Fennec-specific bindings are put into widget/android/fennec/FennecJNI*.
Compile geckoview sources into a separate gecko-view.jar file, apart
from gecko-browser.jar. This lets us separate JNI binding generation,
among other things.
The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
Because I don't know much about the build system, this may not be an optimal
fix. See the added code comments for more details.
Since this is an annotation processor and they tend to be self-analyzing, my
one concern is that this code uses the classpath in some way to identify which
files need to be kept. That being said:
1) I don't think it makes sense to use the classpath in this way, particularly
when the files we want to operate on are passed as a command line argument.
2) My build did not warn me that the generated JNI wrappers have changed so I
expect no side effects from this change.
MozReview-Commit-ID: 5mm6TClO1Su
--HG--
extra : rebase_source : c1ae4f0e9972f9efd8d6593fcbf27a500a6e0b63
Setting GRADLE_USER_HOME in this way ensures all Gradle invocations in
automation have the right flags, rather than just the ones we
remember.
MozReview-Commit-ID: IL53nZVsFuV
--HG--
extra : rebase_source : dafc3c19e75e067481603b6f80692fcea0141b67
This is per-package, so there's no cross-package definition needed.
MozReview-Commit-ID: 8qy2SGJtCh1
--HG--
extra : rebase_source : 5e3cb1959ac560137487d5d0c12002820212aed7
extra : histedit_source : ac2404805e7afc2776c02414ab464d24d3057063
This is cleaning up after Bug 1220906, which removed Old Sync.
MozReview-Commit-ID: EmP4RTMIZ9
--HG--
extra : rebase_source : d97e09ca50dbd2c214c0618d50b7418378697dde
extra : histedit_source : 5148e7d8f5c8f10c36f1fa319ac04fea28432450
Opt-in by adding --enable-gradle-mobile-android-builds.
Gradle dependencies (including the Android-Gradle plugin) are assumed
to be present. Local developers will fetch them from the jcentral
repository.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: 966XgddWgEu
--HG--
extra : rebase_source : 8e8c6156e1d06813c250662e104fd14c621d91ab
extra : source : 306cf0271d3e3a344fcbfd2baf75e0450c288cf1
extra : histedit_source : d17446714236c408699a0953882e84ac3a192380%2Cc21b166af79ef1e00215748820bc2670405ac1dc
On a CLOSED TREE because this is Android only.
When we switched to fine-grained Google Play Services bundling (Bug
1115004), we stopped shipping com.google.android.gms.analytics. That
silently breaks Adjust, which queries the Google Ad ID using
reflection: now the package isn't present! This patch restores the
Play Services libraries that Adjust relies on. (Sadly, this bloats
our APK tremendously.)
There is some hijinkery, however: the Play Services libraries
reference a library (org.apache.http) that is deprecated in Android
23! However, the library is still present on Android 23 devices,
which buys Google time to replace the offending code. This compiles
just fine, breaks the Proguard global optimization pass. To give
Proguard the information, we add the library as a Proguard "library
JAR". This is equivalent to the Google-provided Gradle `useLibrary`
directive.
--HG--
extra : commitid : I4rTyC8lxLd
extra : rebase_source : 96f30d735e898cb9853d53f236ac8e2337186814
extra : amend_source : 3e4d68789b3ef980e4e1d7f743e332bdbb6be176
ON A CLOSED TREE
I have manually verified that this results in a byte-identical
gecko.ap_. This is because after the earlier patches there are no
definitions (or aliases) that are package-local (like .App or
.Webapp), which are the only things (other than the Android package
name) that get rewritten by --rename-manifest-package.
--HG--
extra : commitid : FnCIDrEcNBw
extra : rebase_source : 199968a4064cb8548b303d03a04b4ef05f8a284a
extra : amend_source : 13712c2736c1da47e7e4a277cb25a3c341775ad1
extra : histedit_source : e04d99b417297a1933bf71b4cf315e8c99c4d4b3
This patch turns NativePanZoomController's MotionEvent handler into a
native method, and it adds the WrapForJNI annotations to all native
methods so that bindings will be automatically generated for them.
DONTBUILD NPOTB
This also adds toolkit/ to the Gradle omnijar project.
--HG--
extra : commitid : 2xxf4DfPX1S
extra : rebase_source : f423d0dc72da32bed214c9aa88818b145f386b77
extra : histedit_source : f21b9fe9a4f48fcefb950b9b2275da4207c722b8
Since MOZ_NATIVE_DEVICES builds against play-services-{basement,base,cast},
some ad-hoc de-duplication is necessary.
--HG--
extra : commitid : 2jNIgZpLUq2
extra : source : 0957d3435ac22765d7868cb3c7db1e0787836bc3
We were both lazy and incomplete before. Lazy because .aapt.deps is a
sentinel, and doesn't necessarily see relevant changes, due to
timestamps and deletions. Incomplete because we never forced
generated Java code to be fresh.
--HG--
extra : commitid : JXLe9uWqjhN
extra : rebase_source : 8eaa2d012915ad59d5cd03d7e4a6552ae4db13c1
extra : histedit_source : 231ca7ad88e7965424a8c8a3e80dac68a32980a7
This patch also adds the new base (sic) library play-services-basement.
Note that the package names have changed too:
* play-services-base: com.google.gms -> com.google.gms.base
* play-services-basement: * -> com.google.gms
--HG--
extra : commitid : EcmxZA10rzV
extra : rebase_source : f39b361807a0b8227f3fb9a6d73e066241c8e36c
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
This patch allows you to set MOZ_APP_ANDROID_VERSION_CODE in a branding's configure.sh to specify the exact android:versionCode to use in the final (main) APK. It does *not* modify the android:versionCode used in any other APKs.
--HG--
extra : transplant_source : U%F31E%1AK%3BY%18e.%E8%BD%F3_0%04%C6%84%7B
This allows us to not require dist/fennec/* to exist in the object
directory at gradle-install time. It gets us one small step closer to
being able to sit down to a fresh source tree and open a Fennec
project in IntelliJ.
--HG--
extra : commitid : KNnKth56I1L
extra : rebase_source : b4fae1033335760dd3d6d9b8b71ffb7bbb1a6906
extra : source : 7b5b6adc5ac69fd733f9937dd846c52bff36af0a
extra : histedit_source : cb05d3690f909db51cd6116cc80b070f62338001
This moves a little bit more of mobile/android/base/Makefile.in into
moz.build, and gets closer to moving that aapt invocation into
java-build.mk.
There are no other extra package consumers in the tree. (There should
be a new one shortly: b2gdroid.)
--HG--
extra : commitid : AaYqXYReOSX
extra : rebase_source : d41368ff0bd0736221fdc04ed8299b70c2488c8b
extra : histedit_source : 845efd5ba9f99f4e186c3a5c66affe69eac7fec7
