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
These tests verify that the InstallTrigger API works as expected and that the
old style of signing add-ons is verified correctly. Other applications still
care about this so we don't want to regress it.
This switches most tests that previously expected an unsigned add-on to use an
AMO signed add-on. In apps that care that will allow it to install, in apps that
don't it will be effectively the same as unsigned (untrusted root).
Other tests that actually verify that the old style of signatures are either
seen or not seen are marked as skipped when AMO-signing is required. In some
cases that meant doubling up a few tests to make sure we have coverage.
MozReview-Commit-ID: 6V4U1U1HTqx
--HG--
extra : rebase_source : dff81ecb6f55898296aa3163b25487b7f122c079
extra : amend_source : b2f0083c2c1c936b5f8464ce12a71a9952db0b37
Mostly just declaring globals that Cu.imports defines but there are some actual
bugs here that have been fixed as well as one test that just never ran because
of a hidden exception.
MozReview-Commit-ID: J6uIpYp8ANx
--HG--
extra : rebase_source : 5c19b92e4242088b6fc7a268f255fe9a795928f6
extra : source : 3e5b6df276a9a20fe7b3655656e62a09bc46aaa9
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
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 : ff1cf18a59c7c5633e238090cb6a9abb307ed4fb
Because the add-ons manager hasn't startup up yet we can replace the certificate
database in xpcshell tests with one that claims add-ons are signed by valid
certificates even when they aren't. This allows us to run tests even in builds
where signing cannot be disabled during for the normal application.
This adds an override for all tests except those that are explicitely testing
signing.
--HG--
extra : commitid : 24s3ni5gVYe
extra : rebase_source : a95571dc3556bb035511eea424ba57e8c7007eba
Because the add-ons manager hasn't startup up yet we can replace the certificate
database in xpcshell tests with one that claims add-ons are signed by valid
certificates even when they aren't. This allows us to run tests even in builds
where signing cannot be disabled during for the normal application.
This adds an override for all tests except those that are explicitely testing
signing.
--HG--
extra : commitid : 9Zd5aH92lAQ
extra : rebase_source : 880d0fff51205dc92df91a61fef8b246d2ea2123
nsIFile descriptors use OS specific formats so when trying to read them we have
to catch any failure if the database was written by a different OS. This leaves
the _sourceBundle undefined in only one case which is guaranteed to be during
startup since xpistate.descriptor for the add-on will also be incorrect and so
the full add-on scan will be triggered. That will spot the mismatch and update
the add-on in the database with the correct descriptor.
--HG--
extra : commitid : CNTQu1ESg8Q
extra : rebase_source : faa21ebc1d0b6b91bc81f79072e6d5fb9697bd18
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
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.
Mostly just declaring globals that Cu.imports defines but there are some actual
bugs here that have been fixed as well as one test that just never ran because
of a hidden exception.
MozReview-Commit-ID: J6uIpYp8ANx
--HG--
extra : rebase_source : 9d33fb313aec69e98ac3027d20a6bfc247f27f63
The Widevine CDM crashes on MacOSX 10.6, so only download, expose, and install
it on 10.7 and later.
MozReview-Commit-ID: 51iJpQEB1m7
--HG--
extra : rebase_source : e24e8d8179f22f77c3e5fbfef8489aca7c4fecb9
This currently forbids unknown top-level schema properties, and unknown
permissions. In the future, I'd like to make those warnings rather than
errors, for compatibility purposes, but I think errors are fine for now.
--HG--
extra : commitid : 9jGEwCU9AhR
extra : rebase_source : db16f1e5f9962fb7b24c0e52c05832ae646a57c2
Previously we just checked every newly sideloaded add-on to decide whether to
offer it to the user for opt-in. This adds a new "seen" property (naming could
be better if you have other suggestions) which tracks whether we've ever shown
the opt-in UI for the add-on. It defaults to true for all add-ons and is only
set to false for sideloaded add-ons that default to being disabled on install.
The seen flag can be set to true through the API but cannot be reset to false
as that would allow add-ons to forcibly re-present themselves to the user when
disabled.
The opt-in UI sets the seen flag to true only when it has focus which fixes a
long-standing bug where if you accept the first add-on you see and restart the
other tabs might not show up.
The one slight downside of this approach is that it now requires loading the
full add-ons database on every startup in order to check the seen flag for all
installed add-ons. There are hacky ways we might get around this but they all
involve overloading prefs with even more object data. The good thing is that
we do the load and check asynchronously after most of startup is complete and
the UI is fully loaded so there shouldn't be any percieved impact to startup
time. I've run multiple talos runs to verify that none of the numbers appear to
regress.
--HG--
extra : commitid : AG6pELCYJDa
extra : rebase_source : b824c1626d0c5a77416fa4349ed3dd4d0e96418b
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.
The GMPVideoDecoderTrialCreator was removed from Gecko in bug 1232527, and so
we don't need to set/reset this pref in the GMPProvider any more.
--HG--
extra : rebase_source : 3bb70b21388cdc8adb1aec25cff837a0348a6e3c
Moved these mostly onto the prototype. We couldn't do this before without making
the target of the wrapper a property of the wrappers and we don't want to expose
that but now WeakMaps allow us to get the target without exposing it.
Once change with this approach is that when the test suite shuts down the
add-ons manager it kills the map and so wrappers cease to function. A couple of
tests were relying on accessing wrapper properties after that but that would
have likely been unsafe anyway.
--HG--
extra : commitid : 6OI6dLyM45D
extra : rebase_source : c8a53360ce582186dcdc5cbf0dfc2b5057881eac
Both for brevity and to remove the use of |self = this|.
--HG--
extra : commitid : 7gNXRCzxPxM
extra : rebase_source : 4dccdf8bf99f5979664ca3ca3d9e61f66e217bfe
We used to need explicit names for functions to make stack traces display
properly. The JS engine is smarter now so doesn't need them and they just
make the code messy and redundant.
--HG--
extra : commitid : 4FEIiQYhRQu
extra : rebase_source : 26689d5417f592d0f327f32076245cb4f154229a
For build speed, for correct line numbers in errors, for faster development, for so many reasons.
Still a couple of cases left mostly in XUL files for different strings on Windows.
Bonus: The new lexical scope means ADDON_SIGNING and REQUIRE_SIGNING can just
be declared as regular constants and outside code can't get to them easily.
--HG--
extra : commitid : Kj8khjuCwG2
extra : rebase_source : 2e0a3143900c0c414cda43254306f0c070f8e621
Simple obvious fix. Adds tests by making BootstrapMonitor (which
test_experiments.js and others use for verifying bootstrap startup and shutdown)
verify the list of registered chrome manifests at various points. Without the
fix this makes test_experiment fail as expected.
--HG--
extra : commitid : DhCOtar9Mqu
extra : rebase_source : c194a4d390bbd460b9c17ec09e9c3a219b5025d6
The Android-specific AddonUpdateService has a bit of redundant code
because AddonManagerPrivate has a backgroundUpdateCheck method that does
a lot of the same thing. This patch makes AddonUpdateService call that
method so there's less code and more consistency.
This requires flipping the "extensions.update.enabled" pref, which was
disabled in bug 528588 for showing the XUL addon update dialog. I don't
think this is relevant anymore in native Fennec and with the later
rewrite of AddonManager, so I'm fairly certain it's okay to flip that
pref.
The patch also disables the AddonManager update timer because we have
our own update timer on Android.
