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
