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
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
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
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
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
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.
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.
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.
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.
