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
When built as part of a consuming application, a library's bundle*
target is called but not its assemble* target. (When built by itself
for distribution, a library's assemble* target is called.) This
corrects the wrapper dependencies.
MozReview-Commit-ID: 9ooHMNPK2U4
--HG--
extra : rebase_source : 0b9d979a0066eda86ec39e9700a2e11e8073cea6
The goal of this approach is to tell Gradle to not connect (or allow
it to connect) to the network when fetching dependencies. No Android
automation tasks should fetch from the network, except the toolchain
tasks (which are specially intended to do so).
It's difficult to arrange this without including the `--offline` flag
everywhere. It _should_ be possible to set offline using an
environment variable -- which would allow us to get rid of these
dotgradle-* files -- but offline isn't an option in
https://docs.gradle.org/4.2.1/userguide/build_environment.html#sec:gradle_configuration_properties
(and certainly not in earlier versions either). Therefore,
environment variable that points to an init.gradle file in automation.
Before this patch, the files telling Gradle whether to start offline
were fetched from tooltool. That's just a layer that doesn't need to
be there.
None of this impacts local developers.
MozReview-Commit-ID: LAXktbBu1Az
--HG--
extra : rebase_source : d23801643d32135a87d410bf5e8508da556ef9be
This just isn't used any more; get rid of it. We might want to put
Gradle packages in the tree in the future, so keep
mobile/android/gradle/m2repo.
MozReview-Commit-ID: Gc7TzAqCVsa
--HG--
extra : rebase_source : e60ca18ee19269721c3ecface515c3bba8089f72
We should now only maintain Photon flavor. Remove all Australis related configuration in build scripts.
MozReview-Commit-ID: H4LE8LAso42
--HG--
extra : rebase_source : 2d5a05e43b261d573677834210a7b3fb18aebcac
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
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.
To observe the difference, use `javap -l`. For example, for
automationRelease and automationDebug built with `./mach gradle clean
app:assembleAutomationRelease app:assembleAutomationDebug`, I see
locally:
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/release/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
<snip>
}
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/debug/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
LocalVariableTable:
Start Length Slot Name Signature
0 16 0 this Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu$1;
0 16 1 this$0 Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu;
0 16 2 x0 Landroid/os/Handler;
<snip>
}
MozReview-Commit-ID: 3HmiGkHhowQ
--HG--
extra : rebase_source : c84d8d4b8ac813e49db0c61a30c7098ff2eae3f4
Look for omni.ja to copy from in dist/fennec and in dist/fennec/assets,
but throw an error if we find multiple copies of omni.ja that are
potentially conflicting.
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
Run checkstyle via:
./mach gradle app:checkstyle
This is intended to be added to automation in bug 1258787.
Concerns with this patch:
1) I don't have a maven-metadata-local.xml. However, I didn't take the
snapshotted version and [1] seems to indicate it's unnecessary for my
particular build.
For the addition of future checks, it's worth noting Google's config is
available:
3e4367941c/src/main/resources/google_checks.xml
And this version contains links with descriptions of each of the tasks:
http://checkstyle.sourceforge.net/google_style.html
[1]: https://maven.apache.org/ref/3.3.3/maven-repository-metadata/
MozReview-Commit-ID: ID3X9ZA27b0
--HG--
extra : rebase_source : ad8d3d5255e366362db5cc19985434e5ab5f9559
extra : histedit_source : b0bc07b572f7010c3f15ee76d52619ff5d76ab52
This is a version produced locally from
1d07987217.
I used |./gradlew install| and then copied the pieces out of ~/.m2/repository.
Local builders should never download using this plugin, since |mach configure|
ensures that all the relevant pieces can already be found. It's just useful in
automation; and as an eventual replacement for chunks of |mach bootstrap|.
MozReview-Commit-ID: 9JiFe0xLr99
--HG--
extra : rebase_source : 5bbe5ada7fce0d3e8a702a09da7ff70fd639dc67
extra : histedit_source : aa7049abefafd652b0db2bd03ab15310967e0ad0
DONTBUILD NPOTB
The top source directory configuration requires
mobile/android/gradle/m2repo/**, so it stays. There's no value
changing the location; it contains an Android-specific Gradle plugin.
We note the removal of |mach gradle-install| and point to the new
documentation.
--HG--
extra : commitid : 9Nhz2dnBIgY
extra : rebase_source : 32a2b8a92d57f963feac2bae28fed5a9f1b26f93
extra : amend_source : bf53a0b2d3d4ac0618bc82fe79914bdeaf1c1e0a
This exports the buildDir to Robolectric via an Android-Gradle
buildConfigField, and then lightly massages the existing test runner
to use the exported value.
--HG--
extra : commitid : FKCOBaaJbdn
extra : rebase_source : b47d77c74b6d5179145c9539503a27630a3aa40c
Since MOZ_NATIVE_DEVICES builds against play-services-{basement,base,cast},
some ad-hoc de-duplication is necessary.
--HG--
extra : commitid : 2jNIgZpLUq2
extra : source : 0957d3435ac22765d7868cb3c7db1e0787836bc3
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
DONTBUILD NPOTB
This has always been possible with Gradle -- Gradle doesn't care where
in the file tree resources are found. (Gradle is perfectly happy to
take resources from outside of the root project directory.) IntelliJ,
however, displays resources outside of known "content roots" in
special and frankly unhelpful ways. Here, we avoid that on a
technicality: IntelliJ doesn't acknowledge (or even register a content
root!) for the non-standard AndroidManifest.xml locations set in
build.gradle. This means we don't see odd content roots in unexpected
places in IntelliJ.
With this change, the formerly failing command
mach clobber && mach configure && mach gradle-install
completes successfully. That gets us one step closer to being able to
open Fennec in IntelliJ without running additional commands.
--HG--
extra : commitid : 6KuAzJIpq3Y
extra : rebase_source : 0b85181412d86fa49ee52cf7d612dd3c4028dfb6
extra : histedit_source : 6b8d8171810501a0af053df080b336af70c456b6
DONTBUILD NPOTB
This needed the same dependency changes that the previous part did.
There's a nice simplification here because some of the code is now
being compiled in the containing project (base) and not the (now
removed) sibling project.
--HG--
extra : commitid : IHKXiR8SpLr
extra : rebase_source : 0b2e03f0a76ed17782f0bbaba61adbfa547a6ba2
extra : histedit_source : 0c3420152b2c37dfcbb6e11e6ca58e6c03ad7aca
While testing, I found some issues with the existing dependencies. To
address them, I've made all project preBuild tasks depend on the
(single) root generateCodeAndResources; this should ensure that the
Make integration happens as early as possible. In addition, I fixed
the dependencies syncing the generated resources into the build
directory, which weren't quite right. This works well locally now.
--HG--
extra : commitid : 4Kblf9h0yst
extra : rebase_source : e9e6fa415939f2622a7cfc09f5945e31269338e4
extra : histedit_source : 4cdf1470a0d99b1f805a4fda69d57f425f613421
Technically, branding should be part of the App and not GeckoView, but
we don't have separated resources yet, so in it goes.
--HG--
extra : commitid : 5r00T6BTBRE
extra : rebase_source : ca1411809bb5352617814bc136689d77358fd29c
extra : histedit_source : a435587e3bf16ad3f5457936a0e4efeffa69f9a4
DONTBUILD NPOTB
Project specific test filtering is automagically handled by gradle task graph
--HG--
extra : commitid : 2vx7QzGNVUI
extra : rebase_source : 63254386dca7f0aa5c6a5894f7915b2ed50dd65e
DONTBUILD NPOTB
Straight from http://stackoverflow.com/a/24751182 and the linked
IntelliJ tickets.
--HG--
extra : commitid : AcbSF0042KW
extra : rebase_source : f67e9eecfdf3f452e4fd55901f8eb42b0f3ed22c
DONTBUILD NPOTB
This means we don't require the directory in the object directory at
gradle-install time. We're not concerned if the resource files are
missing, since we have code to ensure they're fresh already; and if
they are missing, we'll quickly fail as we try to process the resource
set.
--HG--
extra : histedit_source : 04767c8e86c7012ed3c46564e5660b17e1355607
extra : rebase_source : 658cedf4a698d603571153cefb128b87a6ad6a2e
extra : commitid : DIwvp3ib9Z9
extra : source : 00e1cd6d04c03a65433b01cea194edf7c9d7c835
extra : amend_source : 244a950264c0d10cf495a3a7d7d5ef52eab2da14
This means we don't require the directory in the object directory at
gradle-install time. We're not concerned if the source files are
missing, since we have code to ensure they're fresh already; and if
they are missing, we'll quickly fail as we try to compile with missing
sources.
--HG--
extra : commitid : IIuTcQiEJ37
extra : rebase_source : 640e8f2005b71d1c79719dcecc56efb8540341fa
extra : source : f8bc8f04b3c01cf62403f09cc3a4b37826e280bc
extra : histedit_source : 34335f47dd33a07585ef8e8a24bdc7cb43b62239
This allows us to not require dist/fennec/* to exist in the object
directory at gradle-install time. It gets us one small step closer to
being able to sit down to a fresh source tree and open a Fennec
project in IntelliJ.
--HG--
extra : commitid : KNnKth56I1L
extra : rebase_source : b4fae1033335760dd3d6d9b8b71ffb7bbb1a6906
extra : source : 7b5b6adc5ac69fd733f9937dd846c52bff36af0a
extra : histedit_source : cb05d3690f909db51cd6116cc80b070f62338001
This was just an oversight. The Gradle configuration referenced
topsrcdir rather than having a symlink via the objdir. This didn't
impact the Gradle build, but it did make the preprocessed_code Gradle
project appear outside of the root Gradle project in IntelliJ.
--HG--
extra : commitid : As00AcCfYkr
extra : rebase_source : 1d5b79f5e4439306a5a9e7d625e39ef97d37d1eb
extra : source : fcec6d827887e3e64ebd610ef4f893d11dde52ab
extra : histedit_source : 70790f27c201462e5346660f5eb39e39303bdc8d
It's convenient to know that the object directory is up-to-date (after
|make gradle-targets|) before any Gradle project builds.
--HG--
extra : commitid : 2WaqMEqw3mx
extra : rebase_source : 2dea8249b329d82d9c89b5defa7e13d4aff60566
extra : source : eb170abcc91b4714874e97b58b371e242aee9699
extra : histedit_source : 92a62bd75dfa289f3ede4592d4a224ad135d3b6b
DONTBUILD NPOTB
We're seeing build failures since 6.5.+ doesn't match 6.5.87. This
shouldn't be fuzzy, and it shouldn't be an ancient version of Google
Play Services either. (In moz.build local builds , we're using a much
more recent version. In automation, I'm not certain what we're
using.)
--HG--
extra : commitid : 6EjfXxM9FJy
This is an information sharing review request. This patch
demonstrates two ways to handle static build flags in the Java source
base.
For MOZ_NATIVE_DEVICES, we /exclude/ certain Java source files. This
is unwieldy but works fine.
For MOZ_WEBRTC, we selectively /include/ certain Javas source
directories. We symlink the directories into the objdir so that the
IntelliJ configuration remains entirely under the project directory --
IJ really doesn't like it when sources are outside of the project
content root. Since two source directories declare the same package
(org.webrtc.videoengine) we can't symlink deep in the package
hierarchy. Therefore, we add top-level source directories sibling to
src/main.
--HG--
extra : commitid : 2huDQAbl5NJ
extra : rebase_source : 8171c7e6944722d6d2f772ea9fae710eb2ecaec4
- Removed old robotium jar in replace for the newer one.
- Newer robotium has packaging changes which were updated in all tests.
- Updated in build.gradle and makefile.
--HG--
extra : transplant_source : %949%F2%F6%10v%9A%CA%8B%FD%EE%05%28%D8%1E%0D%09_%BE%D3
There are several parts to this ticket:
1) Produce javaaddons-1.0.jar, a standalone JAR defining a (versioned)
Java interface suitable for consumption by third-party Java addon
implementations.
2) Support the new V1 interface in the JavaAddonManager.
3) Add Robocop JavascriptTests testing the JavaScript message passing
interface to and from Java.
This patch can be read as "not in tests/" and "everything in tests/".
--HG--
rename : mobile/android/base/JavaAddonManager.java => mobile/android/base/javaaddons/JavaAddonManager.java
extra : commitid : ApOd0Iz9BrZ
extra : rebase_source : 9808487ec3b233f31524e3694d1e997af78a0c84
extra : histedit_source : c8883a01805d7ed39ffb58e8523103260aa72d0b
There are few things happening here:
* A purely mechanical move of test sources into org.mozilla.test.browser.junit3.
This is only to make it easy to specify the suite in Spoon. (But it has the
advantage of making it possible to move files around in IntelliJ, since the
symlink points to src instead of org/mozilla/gecko.)
* Specifying the suite (package name) ended up requiring changes to the
spoon-gradle-plugin anyway. Hence, I've included this custom
spoon-gradle-plugin version locally, while I work to upstream the changes.
* Some Gradle trickery to make |mach gradle runBrowserTests| execute Spoon with
the correct package name.
--HG--
rename : mobile/android/tests/browser/junit3/src/BrowserTestCase.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/BrowserTestCase.java
rename : mobile/android/tests/browser/junit3/src/TestDistribution.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestDistribution.java
rename : mobile/android/tests/browser/junit3/src/TestGeckoBackgroundThread.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestGeckoBackgroundThread.java
rename : mobile/android/tests/browser/junit3/src/TestGeckoMenu.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestGeckoMenu.java
rename : mobile/android/tests/browser/junit3/src/TestGeckoProfilesProvider.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestGeckoProfilesProvider.java
rename : mobile/android/tests/browser/junit3/src/TestGeckoSharedPrefs.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestGeckoSharedPrefs.java
rename : mobile/android/tests/browser/junit3/src/TestImageDownloader.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestImageDownloader.java
rename : mobile/android/tests/browser/junit3/src/TestJarReader.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestJarReader.java
rename : mobile/android/tests/browser/junit3/src/TestRawResource.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestRawResource.java
rename : mobile/android/tests/browser/junit3/src/TestSuggestedSites.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestSuggestedSites.java
rename : mobile/android/tests/browser/junit3/src/TestTopSitesCursorWrapper.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/TestTopSitesCursorWrapper.java
rename : mobile/android/tests/browser/junit3/src/harness/BrowserInstrumentationTestRunner.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/harness/BrowserInstrumentationTestRunner.java
rename : mobile/android/tests/browser/junit3/src/harness/BrowserTestListener.java => mobile/android/tests/browser/junit3/src/org/mozilla/tests/browser/junit3/harness/BrowserTestListener.java
extra : rebase_source : 5eff7e0da0be912838fac0ddad5f6b357800eb45
extra : histedit_source : e76288628e14aeb155d2d3b4033d056c6efdc646
While it might seem like a good idea to disable all of the checks we don't
currently pass, Intellij uses the same lint configuration file as the
command-line invocation and so we'll be more likely to write in new errors by
disabling some checks.
--HG--
extra : commitid : 23gdgWSBmyt
extra : source : 7bd754d48b86b5104bc44067886af81c9315a3b6
DONTBUILD NPOTB
Unfortunately, Gradle just can't handle incremental dexing in our
multi-project and parallel configuration. I see the dreaded
"com.android.dex.DexException: Multiple dex files define ..." error
frequently.
I'm using a downloaded Robotium package instead of the in-tree JAR
file as well, 'cuz it seems to be related.
--HG--
extra : rebase_source : d95c0844082a6deb48966496cb90824f70f6c49d
extra : histedit_source : 2f3d231d9b7139880a924089ab0d523e5e31e6b6
This is just a clean-up: rather than having each subproject have a
generateCodeAndResources build action, we have a single action
(attached to the root project) which all subprojects depend on.
Gradle orders the task DAG accordingly, saving process invocations and
speeding up the build.
--HG--
extra : source : b44dc79fbddb1acc02da12e9926852e67d606584
extra : amend_source : b89249d8af2b7986ab1174f89c150ef8115c71cf
This is a sad, but necessary, loss of generality that will cause the
Gradle configuration to lag behind the rest of the build system over
time. The existing Gradle build worked fine, but IDEA based IDEs can
not yet read build.gradle files containing arbitrary Groovy code. I
can find no alternative to including the values in the build.gradle
file directly. We will just try to keep them up to date.
The versions chosen (compileSdkVersion 21 and buildTools "21.1.1")
correspond to the current versions used on the buildbots. Changing
compileSdkVersion to an integer absolutely requires Gradle-Android
plugin version 1.0.0 or higher, which in turn mandates IntelliJ
version 14.0.3 EAP or higher.
I took the opportunity to update some settings and bump dependency
versions from v19 to v21 as well.
--HG--
extra : rebase_source : 7ada8da4dec7bd56ca3d276d833788d895e12e25
DONTBUILD NPOTB
Local developers should only be building debug APKs. I intend
automation to only build release APKs, and automation will insert the
omnijar and native libraries into the release APK during packaging.
This change requires local developers to delete
$OBJDIR/mobile/android/gradle/app/src/main/{assets,jniLibs}.
--HG--
extra : rebase_source : 455a098eae4586a3010576a4acfde250e8b5837b
DONTBUILD NPOTB
There are significant problems with the combination of Android-Gradle
0.14.4, Gradle 2.2.1, and IntelliJ 14.0.2. The problems include
imports that have no recognized source directories and a quasi-working
debugger that fails to stop on breakpoints.
Rather than claim some support for this configuration, we'll move the
Android-Gradle plugin version forward. This should support both
IntelliJ 14.0.3 (sadly still Early Access Preview only) and Android
Studio 1.0.0.
--HG--
extra : rebase_source : f2394bd65549cef3a2dafb1f83c8d405f0d00124
The important change here is that we allow the Android-Gradle plugin
to be version 0.14.4 or version 1.0.0, which appears to work in
IntelliJ 14.0.2 and in Android Studio 1.0.2.
Testing feedback came from imjalpreet and garvank.
--HG--
extra : rebase_source : 2b93dd91603666f1c6a1d2fe0fa7721d5741bdda
This is a big patch, but it's essentially NPOTB. The part that is POTB
is ... removing Gradle integration from the build. I've implemented
|mach gradle-install| as a substitute for the build system stuff; it's
just so much easier to iterate on a mach command than a moz.build and
Makefile.in.
I'm landing this with self-review because this lessens the impact of the
Gradle integration on the build system and because I am the only person
who understands either the old or the new system.
You'll need to run |mach gradle-install| at top level to configure the
new Gradle integration. But |mach gradle ...| does the right thing
configuration steps too.
This patch rewrites most of the Gradle integration. The major changes
are:
* all .gradle files move into mobile/android/gradle;
* all the Gradle projects live in the object directory;
* mozconfig exposed to all build.gradle files;
* simplification of Android configuration between build.gradle files;
* support for user-specified version of build tools;
* first steps towards supporting builds from the source directory;
* bumps Gradle to 2.2.1;
* bumps the Android-Gradle plugin to 0.14.4.
This is seemingly a step backwards given that we'd prefer to ship the
.idea directory in the source directory. But in fact we get closer to
that; it's possible to run ./gradlew in the source directory and get a
reasonable build. We'll progress with this in time. The win right now
is that the projects are nested, which makes importing work better on
Linux machines.
Unfortunately IntelliJ 13 and 14 now have conflicting Android-Gradle
plugin version requirements, so we now only support IntelliJ 14.0.2 and
above.
--HG--
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/base/AndroidManifest.xml
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/branding/AndroidManifest.xml
rename : mobile/android/gradle/omnijar/gradle_AndroidManifest.xml => mobile/android/gradle/omnijar/AndroidManifest.xml
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/preprocessed_code/AndroidManifest.xml
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/preprocessed_resources/AndroidManifest.xml
rename : mobile/android/thirdparty/gradle_AndroidManifest.xml => mobile/android/gradle/thirdparty/AndroidManifest.xml
This ticket splits a new omnijar project off of base. The new
project's omnijar task knows the inputs (well, those under
mobile/android) and the omni.ja output and only re-packages the
omnijar when the task's output is out of date.
With this modification, local building and most importantly the
Android JUnit test cycle is much improved, because the APK is not
re-deployed when only test code is modified.
In addition, the new project lists the omnijar inputs as "Java" source
directories. Previously, they were listed as "Java resource" source
directories, which meant that the omnijar inputs were packaged into
the final APK. This wasted time and space.
--HG--
extra : rebase_source : 12c94fdfbee9b7c319d5cfb4d7faad254e90abfc
Sebastian Hengst
Nick Alexander
maliu
Jing-wei Wu
Jim Chen
Michael Comella
Sebastian Kaspari
Manav Batra
vivek
Ryan VanderMeulen
Jonathan Almeida
Mark Finkle
Lucas Rocha