Right now, we only expect classes.dex, and even --with-gradle we copy
it out of $topobjdir/mobile/android/base. This commit changes that
for --with-gradle: we only take classes.dex from the given .ap_ file,
and we also handle multiple classesN.dex files (for future multi-dex
support). The moz.build system stays the same.
This avoids an issue with newer Android-Gradle plugins, where the
classes.dex produced could be either in dex/ or in dexMerger/,
depending on whether any external libraries needed merging. By
extracting classes.dex from the .ap_ file, we don't need to know what
Gradle build steps actually occur.
The classes.dex in the package-manifest.in has been irrelevant since
Bug 1260241.
MozReview-Commit-ID: FozKwjTcMzU
--HG--
extra : rebase_source : 62b18c7ffe596be73cec4c9565333eac222b018e
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Bug 1024110 changed the WM class, and bug 1333826 removed the SDK and
the createdevel and related variables.
--HG--
extra : rebase_source : 599ab1998a5d6d471ab7928d782dde1c79ad4734
These magic locations evolve over time. Baking them into
moz.configure is the easiest way to share them across the build
system, and pushing them into a new |mach android *| command continues
a pattern that has been very successful.
MozReview-Commit-ID: CyxVQ0LHHgl
--HG--
extra : rebase_source : 8350d71665f0126aa4ee2c8fec32c4b8e34dc772
These magic locations evolve over time. Baking them into
moz.configure is the easiest way to share them across the build
system, and pushing them into a new |mach android *| command continues
a pattern that has been very successful.
MozReview-Commit-ID: CyxVQ0LHHgl
--HG--
extra : rebase_source : 8350d71665f0126aa4ee2c8fec32c4b8e34dc772
Single-locale repacks do the following:
Download existing APK; unzip APK; update l10n resources; |mach package| with IS_LANGUAGE_REPACK=1.
This is pretty hard to accommodate, but we can try. The key issues
here are to recognize when IS_LANGUAGE_REPACK=1 and not ask for l10n
resources (in particular, strings.xml) to be generated.
We do need to include the freshly built classes.dex when repackaging,
because newer Gradle/aapt doesn't preserve the R.java IDs.
MozReview-Commit-ID: 9FvQtmPOUjg
--HG--
extra : rebase_source : b0440ceb318662bf3c08f2139c51dae5775a6b38
Single-locale repacks do the following:
Download existing APK; unzip APK; update l10n resources; |mach package| with IS_LANGUAGE_REPACK=1.
This is pretty hard to accommodate, but we can try. The key issues
here are to recognize when IS_LANGUAGE_REPACK=1 and not ask for l10n
resources (in particular, strings.xml) to be generated.
We do need to include the freshly built classes.dex when repackaging,
because newer Gradle/aapt doesn't preserve the R.java IDs.
MozReview-Commit-ID: 9FvQtmPOUjg
--HG--
extra : rebase_source : 6a34a8c299138ea39c6703f334c8fd5f49b03237
This commit adds two new xpcshell tests, both of them testing whether the
security state in TransportSecurityInfo includes the new
STATE_CERT_DISTRUST_IMMINENT flag under the correct circumstances.
The first test, test_symantec_apple_google.js, tests the four combinations of
certs that chain to an affected Symantec root: with/without a whitelisted
intermediate, and before/after the notBefore cutoff date.
The second test, test_symantec_apple_google_unaffected.js, tests an unrelated
ca->intermediate->ee chain that does not chain to an affected root, and ensures
the flag is not set.
This patch adds SymantecSanctionsServer to the mozbuild and xpcshell test
infrastructure files to ensure it runs properly on TaskCluster, too.
MozReview-Commit-ID: GtUXH2VFFh
--HG--
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.key => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.key
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.key.keyspec => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.key.keyspec
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.pem => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.pem
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.pem.certspec => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.pem.certspec
rename : security/manager/ssl/tests/unit/tlsserver/cmd/BadCertServer.cpp => security/manager/ssl/tests/unit/tlsserver/cmd/SymantecSanctionsServer.cpp
extra : rebase_source : f399bca5a13db3efa5bbaa5136c8effc3948ed5e
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c
By using the PartialConfigEnvironment, the clients of buildconfig will
depend on config.statusd/ files instead of config.status directly.
Clients can access substs and defines using buildconfig.substs['FOO'] or
buildconfig.defines['BAR'], and then collect file-level dependencies for
make using buildconfig.get_dependencies(). All GENERATED_FILES rules
already make use of this because file_generate.py automatically includes
these dependencies (along with all python modules loaded).
As a result of this commit, re-running configure will no longer cause
the world to be rebuilt. Although config.status is updated, no build
steps use config.status directly and instead depend on values in
config.statusd/, which are written with FileAvoidWrite. Since those
files are not official targets according to the make backend, make won't
try to continually rebuild the backend when those files are out of date.
And since they are FileAvoidWrite, make will only re-run dependent steps
if the actual configure value has changed.
As a result of using JSON to load data from the config.statusd
directory, substs can be unicode (instead of a bare string type).
generate_certdata.py converts the subst manually to a string so the
value can be exported to the environment without issue on Windows.
Additionally, patching the buildconfig.substs dict no longer works, so
the unit-symbolstore.py test was modified to patch the underlying
buildconfig.substs._dict instead.
The other files that needed to be modified make use of all the defines
for the preprocessor. Those that are used during 'mach build' now use
buildconfig.defines['ALLDEFINES'], which maps to a special
FileAvoidWrite file generated for the PartialConfigEnvironment.
MozReview-Commit-ID: 2pJ4s3TVeS8
--HG--
extra : rebase_source : d6bb0208483f9f043e7be1b36907ca13243985f8
Bug 1355661 added support for brotli streams in "jar" files handled by
Gecko, and bug 1355671 made us build the `bro` command line utility that
allows to compress and decompress brotli streams.
This change uses the `bro` command line utility in the packager so that
it can create and handle "jar" files using brotli streams.
However, the `bro` command line utility is not available to l10n
repacks. As, at the moment, we're only hoping that the outcome of using
brotli will be good, we avoid doing all the work to make those work and
just hook things enough to enable brotli, while ensuring l10n repacks
don't break. This involves forcing some files to be deflated, and to
disable some optimizations from the packager.
Things will need to be figured out more properly if the experiment
proves brotli to be worthwhile.
--HG--
extra : rebase_source : a2e0cff67dcaed465fd441ed5d2a7de94b6351c5
The hyphenation dictionaries we ship as part of the build don't depend
on the UI locale, let's stop treating them as localizable content during
repacks.
MozReview-Commit-ID: FTrw4KDtops
--HG--
extra : rebase_source : f6ddb22154fc66da0a7cdc56a4cecb58c9e3d54b
This change makes us upload an `$(PKG_BASENAME).generated-files.tar.gz` archive
alongside other build artifacts which contains all the generated source files
from the build. A change after this will introduce an `upload-generated-sources`
task to take this artifact and upload the individual files to an S3 bucket.
This will be used to provide links to generated source files when they appear
in stack traces in crash reports.
MozReview-Commit-ID: 6yQAdlZ5q3O
--HG--
extra : rebase_source : d92fb17ae737d1360e9724997f6688e29bedef12
extra : source : 14d18d7cf454c4c3d0f6d49d1d01660e06e4be4b
This change makes us upload an `$(PKG_BASENAME).generated-files.tar.gz` archive
alongside other build artifacts which contains all the generated source files
from the build. A change after this will introduce an `upload-generated-sources`
task to take this artifact and upload the individual files to an S3 bucket.
This will be used to provide links to generated source files when they appear
in stack traces in crash reports.
MozReview-Commit-ID: 6yQAdlZ5q3O
--HG--
extra : rebase_source : 3f6ef734c062e0f5e9c2ca433ffad51fdf14b1ad
We should now only maintain Photon flavor. Remove all Australis related configuration in build scripts.
MozReview-Commit-ID: H4LE8LAso42
--HG--
extra : rebase_source : 2d5a05e43b261d573677834210a7b3fb18aebcac
Land date changes to support windows nightlies onto central
This adds support for a seperate installer URL. We need this because in taskcluster the flow goes like this:
-|- Unsigned Build (outputs test files, unsigned .zip and similar files)
\-|- Signing (outputs .zip with signed contents and a signed setup.exe and setup-stub.exe)
\-|- Repackage (takes the signed .zip and generates unsigned update .mar and installers using the signed internal files)
\-|- Repackage Signing (Takes the installers and signs them, and signs the update mar)
L10n tasks for windows need to take the .zip and the completed installer, and want to reuse as much
of the en-US signing as we can, so we pass in the URLs to artifacts from both signing steps in the chain.
MozReview-Commit-ID: 9nIo2CCTh9h
--HG--
extra : rebase_source : 6d2e9a77c9f0cb118ff5389f584034f491bbf0ed
The Windows repackaging tasks need the setup.exe / setup-stub.exe files
from the installer / stub-installer build in order to regenerate a new
installer. In the future, the build can be updated to only produce the
setup.exe / setup-stub.exe files (instead of a full installer).
MozReview-Commit-ID: L3NVUmSw46b
--HG--
extra : rebase_source : 3c6e1b2174ab319a37694f75017c9570d73cfad4
This involves a few changes:
- Remove the .exe from the makensis binaries. which.which will
auto-add it so Windows will keep working - and with it
present we were finding makensis.exe on Linux and trying to
run it, which isn't going to work
- Doesn't bother checking if nsis is 32bit if we're running on
Linux
- Add the -nocd option to nsis (on Linux) because it takes the
current working directory from the target of a symlink rather
than the symlink itself. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704828
MozReview-Commit-ID: CVT8LwS1t8w
--HG--
extra : rebase_source : 2a62327326ba80dfd728048d19f0ff1c90100838
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : 100092c2f2ff609362a724fff60f46dd6e49c94e
extra : intermediate-source : d10f5ccd882b965fcad39914f7c3c930d1301a41
extra : source : a0e257e346ccf3c1db332ec5903241f4eeb9a7ee
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : cd029cdbbcccc1d16f03d63a5f1fdf60be5db4fd
extra : source : a0e257e346ccf3c1db332ec5903241f4eeb9a7ee
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : 19ec875917546abc147b234a815e1a64c204b92a
Python can run these files with 'python -m 7z_exe_foo', but using
'import 7z_exe_foo' is not allowed because the module begins with a
number.
See also: https://stackoverflow.com/a/17487228
MozReview-Commit-ID: 97iDdXlZJ1a
--HG--
rename : python/mozbuild/mozbuild/action/7z_exe_archive.py => python/mozbuild/mozbuild/action/exe_7z_archive.py
rename : python/mozbuild/mozbuild/action/7z_exe_extract.py => python/mozbuild/mozbuild/action/exe_7z_extract.py
extra : rebase_source : 1941986a7e6e56305b742710c73b90a3f7b5226b
This patch fixes the upload/packaging build step for Thunderbird beta builds
MozReview-Commit-ID: K2qcZ4pLvtN
--HG--
extra : amend_source : f16a6747c0260242442a4aa022be1d47a22ab30b
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
--HG--
extra : rebase_source : 477ef683f850ff11cfa128e17855666bb7758a7a
There is no single bug that was reverted, as this work was done over
several bugs, including 1091668, 1123990, 1138535, and 1265272. Most
notable is that we are moving the precomplete generation back into
packager.py rather than spread out over various make variables (except
for the Windows installer, which is still specified in packager.mk).
MozReview-Commit-ID: KDcfR23kKr8
--HG--
extra : rebase_source : ab78f84bb32721289659c893028d681115176c9d
Update also the similar logic in browser/installer/package-manifest.in. The
reason I added the symbolizer is because it'd be useful when someone conduct
jsshell testing/fuzzing.
MozReview-Commit-ID: J9IqFWsnskS
--HG--
extra : rebase_source : db461065f778fc025576b1fc7612642181d94dcd
Generate a separate omni.ja for GeckoView during the packaging step,
under dist/geckoview. Define a MOZ_GECKOVIEW_JAR flag to optionally
include/exclude files in the package manifest.
In bug 1335309, FileFinder was made to default to not find executables,
and zip.py was made to use the default instead. Which made sense for
most uses of zip.py, except for the jsshell package.
So we add a flag to make zip.py able to strip executable (which happens
when the FileFinder is made to find them), and use that flag for the
jsshell package only.
--HG--
extra : rebase_source : 0202f9acd5e6175d3790aaef026e18c6913cf0c6
This removes the UNIFY_DIST and UNIFIED_BUILD variables, as well as the
--unify flag from the packager and UnifiedBuildFinder from mozpack. As a
result the STAGEPATH variable is never defined anymore, so its uses can
be removed as well.
test_unify.py is currently the only mozbuild/mozpack test that fails
without running configure first, and there isn't much point in fixing
tests for things that we don't actually use anymore.
MozReview-Commit-ID: F5q1FPW3Did
--HG--
extra : rebase_source : cadbd237f51c23ea1983135294521d628d16f0df
This is no longer relevant now that we use release promotion instead of
a separate release build with MOZ_PKG_PRETTYNAMES=1.
MozReview-Commit-ID: 11mgGJ7IDaK
--HG--
extra : rebase_source : da8fde3ae36779549b2097fc95d754f558cb88c8
And make it an error not to give it. While the default is True, we do
pass a value of False wherever it makes sense, which happens to be, in
most places.
This is an intermediate step to flip the default from True to False,
ensuring that we don't unwantedly switch some calls to False.
--HG--
extra : rebase_source : 432e03f032fef378af482581685583262e5d2661
Let's use a pristine unpackaged directory of the en-US package, and just
rsync that to l10n-stage. That way, all repacks start off with a copy
of en-US without modifications of the previous repack.
Removing clobber-zip, that hasn't been used in ages, on the way.
Moving the creation of the branding dir to the INNER_UNMAKE_PACKAGE,
which is the command that needs it, to simplify rulesets.
MozReview-Commit-ID: 8WJtaAqjmk1
--HG--
extra : rebase_source : 2c60a09bc09c72d5d8cf3058a66f806059c93751
Upload symbols when --enable-artifact-build-symbols is specified.
Add --enable-artifact-build-symbols to artifact config for linux, linux64,
win32, win64, macosx64.
MozReview-Commit-ID: LpuwfzWXPBH
--HG--
extra : rebase_source : 137466aa3c8c327cf1932e012927fceb451d82ab
Also, now that we're using modern C++11 compilers, we can just rely on
static_assert, instead of the pile of macros used in the autoconf test.
--HG--
extra : rebase_source : 85d507da653d07e6527a971082277486e3502ea2
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
A few notes:
* This doesn't accommodate general OMNIJAR_NAME definitions. The
current name (assets/omni.ja) is baked into the product in a few
places, and is very unlikely to change, so we just error out if this
isn't true.
* This makes the package-manifest.in file authoritative for what goes
into assets/, libs/, and the APK root. Previously,
package-manifest.in wrote into assets/ and libs/ but
upload-files-APK.mk also had a convoluted DIST_FILES filtering
process to work through before a file actually made it into the APK.
* This is intentional about repackaging. It simplifies the repackage
step rather than trying to make unpackage-then-repackage the same as
just package. I pretty much never get repackaging correct the first
time; this should help. (I've manually tested it.)
* The ALREADY_SZIPPED during repackaging is subsumed by the previous
check if UNPACKAGE is set. The custom linker expects stored, not
deflated, libraries, so there's some small legwork to accommodate
that in mozjar.
MozReview-Commit-ID: JvVtIUSX685
--HG--
extra : rebase_source : fd8a9cfe3dc364d23b1065995db599f99e676e38
Builds with Visual Studio 2015 require the Universal CRT. While the
universal CRT may be present on the target machine, there is no
guarantee of this. So, we have to package these DLLs to ensure target
machines are able to run js.exe.
Similar code to what this commit adds exists in build/win32/Makefile.in.
MozReview-Commit-ID: 8LIk1JlKLiT
--HG--
extra : rebase_source : 191c5344a67e9ae1ce249ae2007f193dc9f6de4e
This is several hundred lines of make goo that makes upload-files.mk
even harder to read than it actually is. Extract it to its own file.
I performed a `hg cp` to preserve file history so blame continues to
work.
MozReview-Commit-ID: IpoPE79m9SX
--HG--
rename : toolkit/mozapps/installer/upload-files.mk => toolkit/mozapps/installer/upload-files-APK.mk
extra : rebase_source : 1c3ce7596a89994fd37b9230de9752c441751877
This file is so hard to read. Add some indentation to make it easier to
grok.
I also converted some useless tabs to spaces.
MozReview-Commit-ID: 7DFKeW66uD6
--HG--
extra : rebase_source : fb816ece4dba7a7971e8f00a4f651a1f8adcf633
32-bit PGO builds need to modify the PATH to find pgortXXX.dll. We were
doing this for Visual Studio 2013 (VC12) in 2 locations. We weren't
doing it for Visual Studio 2015. This resulted in a failure to launch
PGO instrumented executables because pgort140.dll could not be found.
This commit refactors the PATH munging to support Visual Studio 2015.
MozReview-Commit-ID: 4EKf8gjcNH6
--HG--
extra : rebase_source : 2772558b06202d26583401bc41e56da8c5a69ef4
There's no slick way to determine that we're doing a single local
repack, and it's not worth adding a new flag just for this situation.
So let's not sign the bouncer APK if tests are disabled; since tests
are disabled during single local repack packaging, this should be
sufficient. This makes the bouncer APK just like the Robocop APK.
MozReview-Commit-ID: AaHUEMhcqMy
--HG--
extra : rebase_source : e386c139613f7bfc83b4e7a28e905a6489171c5a
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
The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.
This isn't sensible for b2gdroid, but that project should never enable
the bouncer APK anyway.
--HG--
extra : commitid : 5KSz5ooYeb1
extra : rebase_source : f30abc9b2553493e2a494497c0eafb22ac866890
extra : source : 50bcadca213183aaa64e39632892b8f00957dcfc
extra : histedit_source : 00085fea29a4289d96dbd08b0b45b4ea6780fd26
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
--HG--
rename : mobile/android/javaaddons/Makefile.in => mobile/android/bouncer/Makefile.in
rename : mobile/android/app/assets/example_asset.txt => mobile/android/bouncer/assets/example_asset.txt
rename : mobile/android/javaaddons/moz.build => mobile/android/bouncer/moz.build
rename : mobile/android/base/resources/drawable-v21/logo.xml => mobile/android/bouncer/res/drawable-v21/logo.xml
rename : mobile/android/base/resources/drawable/logo.xml => mobile/android/bouncer/res/drawable/logo.xml
extra : commitid : 1XkuX1F0pMb
extra : rebase_source : c49ac53697927b0f3d1ee47bc1e7035c1b465e99
extra : source : aaa420ed66d754ecc17b19f5a12297d24371f1ca
extra : histedit_source : 0e3e2fa225c48ba48df72ff116fd62a7b1ef5ed2
This isn't sensible for b2gdroid, but that project should never enable
the bouncer APK anyway.
--HG--
extra : commitid : 5KSz5ooYeb1
extra : rebase_source : 71ea30ce85ba33f58d887d3f90367103f99e0eff
extra : histedit_source : cf91111ebe61f87d64c304206e4ddc409aa26535
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
--HG--
rename : mobile/android/javaaddons/Makefile.in => mobile/android/bouncer/Makefile.in
rename : mobile/android/app/assets/example_asset.txt => mobile/android/bouncer/assets/example_asset.txt
rename : mobile/android/javaaddons/moz.build => mobile/android/bouncer/moz.build
rename : mobile/android/base/resources/drawable-v21/logo.xml => mobile/android/bouncer/res/drawable-v21/logo.xml
rename : mobile/android/base/resources/drawable/logo.xml => mobile/android/bouncer/res/drawable/logo.xml
extra : commitid : 1XkuX1F0pMb
extra : rebase_source : 3154b4569efd4cccb4d5f72ff9bbff60d2744d3b
extra : histedit_source : 5e10ab9825bcf653a5a109c8e502658d52aedd79
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
--HG--
extra : commitid : BLgM6ZCm9AY
extra : rebase_source : a0896616f79f5a961476e4d2df9745516c58b44a
extra : source : e228040a044b7ff7363a178da2cb0b8b42724048
extra : histedit_source : 0b8f087bc6d70fa42401f4a2476898139bdf606c
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
--HG--
extra : commitid : BLgM6ZCm9AY
extra : rebase_source : 572d1ff35a02505f452fee67130b48c8df4499b5
extra : histedit_source : 0b8f087bc6d70fa42401f4a2476898139bdf606c
Right now, each incremental build produces a new set of GeckoView
library files, but the previous files don't get cleaned up, and you end
up with a bunch of old libraries in your objdir. This patch cleans up
the old files before producing new ones.
geckoview_example is broken and obsolete, and we haven't maintained it
for a long time. We should remove it from the tree, allow GeckoView AARs
to build, and rely on other example GeckoView projects that live on
GitHub.
This builds the Robocop tests with |mach build mobile/android|, making
it easier for developers to build Fennec and the tests at the same
time.
--HG--
rename : build/mobile/robocop/AndroidManifest.xml.in => mobile/android/tests/browser/robocop/AndroidManifest.xml.in
rename : build/mobile/robocop/Makefile.in => mobile/android/tests/browser/robocop/Makefile.in
rename : build/mobile/robocop/README => mobile/android/tests/browser/robocop/README
rename : build/mobile/robocop/moz.build => mobile/android/tests/browser/robocop/moz.build
rename : build/mobile/robocop/res/values/strings.xml => mobile/android/tests/browser/robocop/res/values/strings.xml
rename : build/mobile/robocop/robotium-solo-4.3.1.jar => mobile/android/tests/browser/robocop/robotium-solo-4.3.1.jar
extra : commitid : BuNBjgXdm1d
extra : rebase_source : c36b8bf0183d8f5821b7f7839668ca963065d894
extra : histedit_source : a86fef3b834420ea496a9c2644ca72786a2d7da9
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
Mozharness isn't part of the test package, so shouldn't really be packaged during 'package-tests'.
--HG--
extra : commitid : LIK7qJMSPHi
extra : rebase_source : 644c8dd6e0e993b063709ba06e9634d52cb6596d
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
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
This just allows a little versatility for consumers such as b2gdroid,
which are Fennec-like but don't have MOZ_APP_NAME=fennec.
I elected to pass appname as a parameter rather than modify the
existing distdir because I expect to want to differentiate, in some
way, the output AAR files based on the underlying name. That is, in
future we might generate geckoview-fennec-VERSION.aar and
geckolibs-b2gdroid-VERSION.aar, or stuff the name into the Ivy version
information, or...
This also fixes a typo in one of the JarFinder instantiations.
--HG--
extra : commitid : CnJKouGgkh1
extra : rebase_source : 5767e66ea53e14dd6468adec741773a02a6e2d3a
packager.py itself has been able to do preprocessing since the beginning.
For some reason, Makefile.in-driven preprocessing was kept back then, and
never was removed, and even worse, concatenation was added on top of it.
There is however a downside to the current way of doing things: error
reporting is given relative to the given manifest, which in the current
case is the preprocessed/concatenated file, so line numbers don't match
what is in the file in the source tree. However, when packager.py does
preprocessing itself, line numbers are reported properly.
Thus, switch all package manifests to packager.py-driven preprocessing.
This is a small optimization that will also make it easier to flip the
MOZ_DISABLE_GECKOVIEW conditional. We don't currently package
geckolibs without geckoview, and it's reasonable to do both if we want
one.
--HG--
extra : commitid : FcLlG6E3PRQ
extra : rebase_source : ea22994bfa6815468763128995d41c0d6c625d60
extra : histedit_source : a25e0c5c4b5a97bde8871b5e4139e0f0fd4f6a36
DONTBUILD ON A CLOSED TREE: Android-only and the build changes are cosmetic.
Very much a first cut, but I'd like to get some Fennec early adopters testing.
This adds:
* |mach artifact install| to fetch and install Fennec binaries;
* |mach artifact last| to print details about what was last installed;
* |mach artifact {print,clear}-caches|, for debugging.
This code is exposed as a new mozbuild.artifacts Python but it's not
particularly general. My intention was to get things out of the mach command
more than produce a general artifact fetching API. We can leave that bike
shed to Bug 1124378.
I've been testing this with --disable-compile-environment and it works well
locally, although there's no reason a knowledgeable developer couldn't use
this in conjunction with a fully-built tree. (I don't know when such a
situation would arise, but I know of no technical impediment.)
--HG--
extra : commitid : 1T28aVfArqF
extra : rebase_source : b8c11244de8be0a14d605853f30cd47312d0a4ba
extra : histedit_source : 78a224501cd3cf0f86707c9c9549b61b4b248ba7
Now that we don't have to worry about XPCShellErrorReporter being invoked at
weird times, we can get rid of this nastiness - though it unfortunately means
getting rid of one of my best comments in the tree. :-(
Nick Alexander
Brindusan Cristian
Kris Maglione
Hector Zhao
Mike Hommey
Sylvestre Ledru
Tom Prince
Ting-Yu Chou
shindli
Sebastian Hengst
Bill McCloskey
Csoregi Natalia
J.C. Jones
Matt Howell
Zibi Braniecki
maliu
Mike Shal
Chris Manchester
Tom Ritter
Axel Hecht
Ted Mielczarek
Eric Rahm
Wes Kocher
Jing-wei Wu
Justin Wood
Gregory Szorc
Ryan VanderMeulen
Adam Gashlin
Chris AtLee
Ronald Claveau
Aki Sasaki
Carsten "Tomcat" Book
Bobby Holley
Joel Maher
Jim Chen
Xidorn Quan
Edmund Wong
Paul Yang
Rob Thijssen
Alessio Placitelli
Mark Banner
Benjamin Smedberg
Florian Quèze
Nick Thomas
Robert Strong
Jim Mathies
Eugen Sawin
Phil Ringnalda
Brad Lassey
Maja Frydrychowicz
Jared Wein
Towkir Ahmed
Justin D'Arcangelo
Kai Engert
George Wright
Myk Melez
Henrik Skupin
Rail Aliiev
Gijs Kruitbosch
Nigel Babu
Dave Townsend
Birunthan Mohanathas
Georg Fritzsche
Masatoshi Kimura
Ben Hearsum
aleth
Tooru Fujisawa
Ehsan Akhgari
Shu-yu Guo
Andrew Halberstadt
Julien Pagès
Edwin Flores
David Keeler
Kyle Machulis
"Chris AtLee"
Bobby Holley