When driver letter is upper case, `commandLine.execute` seems to be failed.
So I would like to change MOZILLABUILD environment variable to lower case.
Differential Revision: https://phabricator.services.mozilla.com/D137976
This allows us to decouple GeckoView from exoplayer2, have it's own Java
settings and not pollute GeckoView's dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D133792
The fact that the test runner app is defined inside the geckoview test package
has always felt like a hack to me. I've mistakenly thought that
TestRunnerActivity was used in GeckoView's junit tests many times (even though
that's not the case).
From what I can see, there's no way to generate an AAB package for androidTest,
so to be able to run Gecko tests as AAB we finally need to define the
TestRunner as an ordinary package instead.
Differential Revision: https://phabricator.services.mozilla.com/D127320
This patch introduces a new local.settings field: mozilla-central.mozconfig.
This field can be used to set a custom mozconfig file for the gradle build (and
for Android Studio).
The environment variable MOZCONFIG will take precedence over what is defined in
local.settings to allow Gecko engineers to use multiple mozconfig files.
Co-Authored-By: Nick Alexander <nalexander@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D124830
Examples are currently in github. They should be kept alongside the documentation and code and built along with other projects in Android Studio.
Differential Revision: https://phabricator.services.mozilla.com/D53978
--HG--
extra : moz-landing-system : lando
Examples are currently in github. They should be kept alongside the documentation and code and built along with other projects in Android Studio.
Differential Revision: https://phabricator.services.mozilla.com/D53978
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
Print debugging a task that runs gradle has been really annoying as gradle
reads the output of 'mach environment' and fails as soon as a debug line shows
up.
What's worse, is it redirects stderr into stdout so even printing to
'sys.stderr' fails. This fixes that so writing to stderr will at least work.
Differential Revision: https://phabricator.services.mozilla.com/D47608
--HG--
extra : moz-landing-system : lando
The inline comment explains what is happening here. The issue is that
client.mk is setting MOZ_OBJDIR (and autoconf.mk is setting CC/CXX and
others) as part of `mach build`, which means that recursively invoking
`mach build` sees a different environment, and that triggers
reconfigure.
In some situations we can avoid this by recognizing that the
environment has changed and setting it back to what it was at the time
of `mach build` before client.mk adjusts it.
Differential Revision: https://phabricator.services.mozilla.com/D30425
--HG--
extra : moz-landing-system : lando
Since gradle doesn't run on sh.exe, it requires python path to run mach command.
But gradle doesn't have a way to detect python.exe.
When using MozillaBuild, it sets MOZILLABUILD environment value, so we can
detect python path in MozillaBuild using it if available.
Differential Revision: https://phabricator.services.mozilla.com/D20454
--HG--
extra : rebase_source : bba5ae6b8b53c408e8f80db3202458e177eecca4
We want annotationProcessors to be compiled and archived into a JAR at
build time, ready to generate JNI wrappers. (That is, until we turn
the whole thing into a real annotation processor.) But even if we do
use a real annotation processor, we still need to generate SDK
bindings, which is less clearly expressed as an annotation processor.
(It's more of a build step.)
Gradle provides a huge number of ways to organize build logic to
achieve this: see
https://docs.gradle.org/current/userguide/organizing_build_logic.html.
Unfortunately, the best such way -- putting the code into
$topsrcdir/buildSrc -- has key disadvantages:
1) it pollutes the top-level $topsrcdir, and there's no way to change the
location of buildSrc (https://github.com/gradle/gradle/issues/2472);
2) it's complicated to have a dependent project
(mobile/android/annotations) expose its code via a buildSrc project;
3) using buildSrc at all appears to conflict with the Android-Gradle
plugin version that we are using.
Therefore, this commit does something much simpler: it adds a
Java-only project and uses the resulting Gradle "Jar" task and archive
output as input to the existing Gradle "generate JNI wrappers" task.
MozReview-Commit-ID: 2OyYLPneE1M
--HG--
extra : rebase_source : d99b74a0a1e0bb3e8f4d4540978328388e5c2e42
We need to bump the Gradle Deps task, which fetches dependencies, to
include new test dependencies; and use freshly uploaded tooltool
archives (manually uploaded) containing the new test dependencies.
MozReview-Commit-ID: 8bNOVQPHlk6
--HG--
extra : rebase_source : 0c80117fb58e43f9c857027941f0a14f03b97f13
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
MozReview-Commit-ID: 4fCY504UgPu
--HG--
rename : mobile/android/app/base/lint.xml => mobile/android/app/lint.xml
rename : mobile/android/tests/background/junit4/resources/robolectric.properties => mobile/android/app/src/main/resources/robolectric.properties
extra : rebase_source : 689e879dd4ec4402d5e7f948fa5f8be256284a88
extra : intermediate-source : 746468f5d9798ff404a80cd957664e2b69a0e97c
extra : source : a7f63b3721cd3ba105990bbb37a87044383d26d9
extra : histedit_source : 6bdcfa36ddb45bbfd518c5459e4940e29a30f1c2%2C4bfef3b752a85174f1aa1f2226a286ac30bae25a
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
--HG--
rename : mobile/android/app/base/lint.xml => mobile/android/app/lint.xml
rename : mobile/android/tests/background/junit4/resources/robolectric.properties => mobile/android/app/src/main/resources/robolectric.properties
extra : commitid : 2aEbQRv0D7m
extra : rebase_source : c0f014e3fba7008967f8f9782125f940fcc89fe6
extra : amend_source : 46bfdfb116c026da490750a23a9c9188ab4cdf9a
extra : source : a7f63b3721cd3ba105990bbb37a87044383d26d9
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
--HG--
rename : mobile/android/app/base/lint.xml => mobile/android/app/lint.xml
rename : mobile/android/tests/background/junit4/resources/robolectric.properties => mobile/android/app/src/main/resources/robolectric.properties
extra : commitid : BSiXkLh5kSh
extra : rebase_source : ee178b04cd727e11a65f0550d88f1cd951cc5b7a
extra : amend_source : 45f49104a4687cf4cb71391c3f3ac2def8ef716a
This is the last Gradle project that isn't in the srcdir. Since base/
doesn't have the correct package prefix directory structure, we still
need to symlink, but we only need one link. This effectively
deprecates |mach gradle-install|.
This should improve the robustness of our Gradle configuration,
ensuring that we always have projects to import. Since
settings.gradle executes very early in the IDE import project
sequence: before Gradle project evaluation time, and thus before any
Gradle task is executed, we should always see a complete project. (It
was possible to see incomplete Gradle configurations if |mach
gradle-install| hadn't been run at just the right time.)
--HG--
extra : commitid : 4zK7U5PAypH
extra : rebase_source : 91f8534a89f0311b36bd39f502e2f7609a1d78b0
DONTBUILD NPOTB
The :omnijar project is for IntelliJ only; adding it neatly labels
folders we consider part of the omnijar in mobile/android. The JAR
produced is not used.
We add an evaluation-time dependency from :app to :omnijar so that we
can declare the set of omnijar folders exactly once. We'd prefer to
have the dependency in the other direction (to save evaluation time)
but there's an interface mismatch between the two Gradle model types.
See comments in the :omnijar project.
This is delicate.
--HG--
extra : commitid : 4TLicjMC7Bn
extra : rebase_source : 5dd4ab1e1fcdb296b46bc892b9e10414baadee61
I don't want to cut consumers of $OBJDIR/mobile/android/gradle over
yet, so this doesn't remove the existing 'thirdparty' project.
--HG--
rename : mobile/android/gradle/thirdparty/AndroidManifest.xml => mobile/android/thirdparty/AndroidManifest.xml
rename : mobile/android/gradle/thirdparty/build.gradle => mobile/android/thirdparty/build.gradle
extra : commitid : 8L8SU60bAig
extra : rebase_source : 0974b1e31821693b172f73119c4988c82a069a44
The sub-project definitions are still in the object directory (and
still installed by |mach gradle-install); over time, we'll migrate
them out.
The Gradle wrapper and {settings,build}.gradle in topsrcdir are
identical to those in mobile/android/gradle. I don't like the
duplication, but I also don't want the burden of keeping the two
configurations identical. We'll move away from the configuration
using mobile/android/gradle as quickly as we can.
--HG--
rename : mobile/android/gradle/build.gradle => build.gradle
rename : mobile/android/gradle/gradle/wrapper/gradle-wrapper.jar => gradle/wrapper/gradle-wrapper.jar
rename : mobile/android/gradle/gradle/wrapper/gradle-wrapper.properties => gradle/wrapper/gradle-wrapper.properties
rename : mobile/android/gradle/gradlew => gradlew
rename : mobile/android/gradle/settings.gradle => settings.gradle
extra : commitid : IkXCiKfkha1
extra : rebase_source : 4142fe37cd7e036d41fb122fe31cd232fcfdfc80
Makoto Kato
Agi Sferro
Butkovits Atila
Csoregi Natalia
Tiger Oakes
Emily Toop
Daniel Varga
Mihai Alexandru Michis
Nick Alexander
Andrew Halberstadt
maliu
Wes Kocher
Nigel Babu