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
GARBAGE is set automatically by PP_TARGETS.
The fragment does not need to be preprocessed at all, since it is
itself included in a preprocessed file. Including the fragment in
all_resources is therefore not needed, since it is just itself
included in a file.
--HG--
extra : commitid : Bcc3HOOnCRk
extra : rebase_source : f05854ca368b51e2e5ac9f1f17feda29a570cb5f
extra : histedit_source : 007f5d116f333fc1a537057a04507d3c327d6c60
Because we switched annoations from gecko-mozglue.jar to constants.jar,
we should update the corresponding classpaths when processing
annotations during code autogeneration.
gecko-mozglue.jar is still needed during the javah step because
gecko-browser.jar has a dependency on
org.mozilla.gecko.mozglue.JNIObject.
We have had singular ANDROID_ASSETS_DIR in Makefile.in for a while.
Fennec itself does not use the existing Makefile.in Android code, for
complicated historical reasons.
This makes the existing variable moz.build-only; generalizes the
existing variable to an ordered list; and adds the equivalent use of
the new list to the Fennec build, with a simple example asset.
This patch also updates the packager to include assets packed into the
gecko.ap_. Without the packager change, the assets/ directory in the
ap_ gets left out of the final apk. This whole approach is totally
non-standard but is more or less required to support our single-locale
repack scheme.
--HG--
extra : commitid : 4EAh1UNGNWT
extra : rebase_source : 5e5b4c4a120c3b4cc776c9f9380ddd2f9b63587e
extra : source : 0ddce3eb833e6d6180a19928a9b45d5d12f1d7fa
JNIObject is the base class for any class that wish to use per-instance
native methods. It encapsulates the long native pointer that used to be
in NativeJSContainer.
Copy the natives header from the objdir to the source directory,
along with the generated wrapper files from before.
The patch also removes saving the originals to .old files to avoid
producing untracked files in the source tree.
I considered three ways to do this:
* one, as a Python script executed with $(shell);
* two, as a Python script that writes an include file for the preprocessor;
* three, as a function exposed to the moz.build sandbox.
I rejected two because it's both tied to the preprocessor, and awkward
to make handle the dependency on the buildid (in a file) and
additional build defines (in config.status).
I rejected three because I know of no precedent for this approach, and
it hides the dependency on the buildid.
One doesn't handle failures in the script gracefully, but neither did
the existing approach. This patch is at least testable.
--HG--
extra : commitid : 8dfw1ri7qjr
extra : rebase_source : da0e5ec705e0ac4c795bd2d7892f73857a1699ac
We migrated to use MOZ_MIN_CPU_VERSION in moz.build some time back.
--HG--
extra : commitid : GoBGHdceR8r
extra : rebase_source : 8b9d82ec76459154296598610f71b1ea5fdae372
