This bumps the NDK version to r10e.
Previously, we used brew to install android-sdk and a custom version
of android-ndk. That makes it hard to control the installed versions.
This installs from downloaded archives, which unifies the Mac OS X
approach with the straight-forward Linux approach.
--HG--
extra : commitid : E7hEqsyy8Gw
extra : rebase_source : 9ea27e7d2ae3fbaaa3efbabdd701521981bec877
extra : histedit_source : c07c80c50ac066dc6808e7ccf96f0bc14dc09df2
For popular modules used by many DevTools add-ons, add shim files which wrap the
modules and make them available at their previous location.
Each shim includes a deprecation warning to make devs and users aware of the
issue.
--HG--
rename : devtools/server/dbg-server.jsm => devtools/server/shims/dbg-server.jsm
rename : devtools/shared/client/dbg-client.jsm => devtools/shared/shims/dbg-client.jsm
extra : commitid : H7Y9k2ADf0u
extra : rebase_source : 2bd193ecd4f2baeb8b14c14c63884d3a318a0840
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
--HG--
extra : commitid : KsbH21csjH4
extra : rebase_source : bc7c08de1ec6e802261b8cd294d88ee2c4e75c2d
Rather than just add suport for a new homepage, I think it's wise that we add support for android preferences from distro files.
I've added support from within the preferences.json file, an example file would look like this:
{
"Global": {
"id": "sample",
"version": 1.0,
"about": "Sample Distribution"
},
"Preferences": {
"privacy.donottrackheader.enabled": true
},
"LocalizablePreferences": {
"browser.search.defaultenginename": "Bugzilla@Mozilla"
},
"AndroidPreferences": {
"homepage": "http://www.mozilla.com"
}
}
--HG--
extra : commitid : INGL1YVHSdf
extra : rebase_source : 8b0ebc5a94e653c86254232ca6c752f09602a4b7
extra : amend_source : b5627935333b0f1dbae8a9e76c427eef21c962ca
The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
--HG--
extra : commitid : FuPUB9X4oYJ
extra : rebase_source : cfcd31d7da5f5b636a2ec11546dbada973d681de
extra : histedit_source : 3df840dc502c6ee4177f1858920d1260e4dc27af
The new tar.xz file was produced by taking the existing file, removing
extras/*/support, and copying over the extras/*/m2repository from my
local machine. These directories are all the same across all
installs, to the best of my knowledge. I used |xz --compress| with no
additional options.
--HG--
extra : commitid : 3gSpjaOw7Xj
extra : rebase_source : 2cdc5039cc2046f8f716ca650f18d53e8d700877
extra : histedit_source : 52eeb368a09cf7a39af82dca1b85c173a101c070
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 commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
--HG--
extra : commitid : 25Ft0BFs88O
extra : rebase_source : 05e3d1da8d42fa89d06ef48baee17bb77df5bd59
extra : histedit_source : 95b82309aca15c5a3c5f5a0eafbdcf75c5e8dfc0
Wes Kocher
Carsten "Tomcat" Book
Nick Alexander
Fabrice Desré
Martyn Haigh
vivek
Michael Comella
J. Ryan Stinnett
Dave Townsend
Prateek Arora
Ahmed Khalil
Prabhjyot Sodhi
Phil Ringnalda
Josh Matthews
dominique vincent
Christian Schmitz
Seth Fowler
Allison Naaktgeboren
Chris Peterson
Stephanie Ouillon
Jordan Lund