We want to use the Palette library for getting a fallback accent colour for lightweight themes, however because of bug 1318667, we might have to continue using our own implementation of getDominantColor on x86 devices.
Therefore we move this into BitmapUtils, so we can have a central location from which to switch between our own and the Palette library implementation.
MozReview-Commit-ID: 52WsfZbW12x
--HG--
extra : rebase_source : b0eb60c25355d1a13418844b5684e4356225e8c3
We want to use the Palette library for getting a fallback accent colour for lightweight themes, however because of bug 1318667, we might have to continue using our own implementation of getDominantColor on x86 devices.
Therefore we move this into BitmapUtils, so we can have a central location from which to switch between our own and the Palette library implementation.
MozReview-Commit-ID: 52WsfZbW12x
--HG--
extra : rebase_source : b7e66c027ef6c4a6aa01fcda6d17b6afb2e854a9
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c
Even when building the "app" module in debug mode, by default Gradle still chooses to build all dependencies in release mode, which means that all of our own source files that reside in such a library (geckoview, respectively thirdparty) will e.g. be missing debug info for local variables.
MozReview-Commit-ID: owZr9yKtYI
--HG--
extra : rebase_source : ae09795ebe70bf4213cd3d145efa355712c702a0
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 was only ever used to automatically fetch Android SDK
dependencies in the android-gradle-dependencies job in Task Cluster.
That function is now provided by newer Android-Gradle build plugins.
MozReview-Commit-ID: Adrxm2rAPlZ
--HG--
extra : rebase_source : 6cccb53e2ebc2642ee6c61ef13fcb6d8321b67cf
Include necessary WebRTC files and permissions for GeckoView. For
permissions, we need to add the RECORD_AUDIO permission to GeckoView's
AndroidManifest.xml, but since the file is not preprocessed, we can't
use an `#ifdef MOZ_WEBRTC` block, so I think we'll just have to
unconditionally include the permission.
MozReview-Commit-ID: IUd8FFMsW99
--HG--
extra : rebase_source : b75462d53e6bd05b324e8551c888853c8678ec6b
This patch does two things:
- add a Gradle-only ANDROID_COMPILE_SDK_VERSION substitution;
- uses it while uniformizing all of the Gradle Android SDK version
configurations.
The approach is fairly standard (and we were using it already); see,
for example
https://medium.com/@ali.muzaffar/gradle-configure-variables-for-all-android-project-modules-in-one-place-5a6e56cd384e
This will make bumping the Gradle configuration versions forward
easier.
MozReview-Commit-ID: 1j5siCvR5qt
--HG--
extra : rebase_source : 07afb00de0e4a72af4026eb19ff4f2530c119336
We want HTML reports for humans and XML reports for processing. It's
unfortunate that we need to handle this manually, but here we are.
MozReview-Commit-ID: BKEhl7cInPP
--HG--
extra : rebase_source : 8d48b664903bce32def8f0762a86d31c250c3853
Includes re-importing gyp files removed from upstream in v56, and then
updating them to match the BUILD.gn file changes.
--HG--
rename : media/webrtc/trunk/webrtc/call/audio_send_stream.cc => media/webrtc/trunk/webrtc/call/audio_send_stream_call.cc
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1320310#c14, the fix
for Bug 1320310 interferes with the Android Studio launch experience.
This reverts that change for non-official audiences, i.e., the
local{Old} configurations used by developers.
MozReview-Commit-ID: 2Mc5MUj8Utl
--HG--
extra : rebase_source : 62d113e85453bb695b59e780653a34cab199872f
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
The Java Addons mechanism never got traction and is not Web Extensions
compatible. Removing it simplifies the product and the build system.
MozReview-Commit-ID: ABUxkqqMISa
--HG--
extra : rebase_source : 346f88882774f072316714cf637a54d771d81a9a
Layer on the hacks! This:
1) Reinstates the <activity-alias android:name=".App"> that we have in
the moz.build produced Android manifest. I found no way to do this
using placeholders or the manifest merger.
2) Culls manifest entries provided by
com.google.android.gms.measurement. We know they're not necessary,
since they're not present in the existing Fennec Android manifest.
These are strictly workarounds to avoid doing the real work of fixing
the issues. To fix 1), we'd need to migrate all existing users with
homescreen shortcuts to .App. This could be difficult, especially if
partners have deployed packages out of our update control. To fix 2),
we'll need to upgrade our Google Play Services to at least version
9.0.0 and then use the finer-grained AAR dependencies to not build
with the measurement split at all.
MozReview-Commit-ID: 21CaZ2KMeIa
--HG--
extra : rebase_source : c9aff7c414c13843c4e54267c95941fa35bc1001
Layer on the hacks! This:
1) Reinstates the <activity-alias android:name=".App"> that we have in
the moz.build produced Android manifest. I found no way to do this
using placeholders or the manifest merger.
2) Culls manifest entries provided by
com.google.android.gms.measurement. We know they're not necessary,
since they're not present in the existing Fennec Android manifest.
These are strictly workarounds to avoid doing the real work of fixing
the issues. To fix 1), we'd need to migrate all existing users with
homescreen shortcuts to .App. This could be difficult, especially if
partners have deployed packages out of our update control. To fix 2),
we'll need to upgrade our Google Play Services to at least version
9.0.0 and then use the finer-grained AAR dependencies to not build
with the measurement split at all.
MozReview-Commit-ID: 21CaZ2KMeIa
--HG--
extra : rebase_source : c45694814145946425031064cf59d3b863d3bde4
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
Since we're Proguarding the automation build now, we shouldn't need to
multiDex anymore -- even in beta.
MozReview-Commit-ID: 6Yc73Vi9Fhd
--HG--
extra : rebase_source : cdfb01a47dc05dfafc4ba67cdb30f86dbd5aa4ec
moz.build achieves better results than Gradle, and I can't fully
explain why that is. At first I thought it was due to
-optimizationpasses, which is 6 for MOZILLA_OFFICIAL; however, it's
not -- I see no change (let alone an improvement), when I set the
number of passes to 1, 6, 10, or 100. I think there are two things at
play. First, moz.build strips debugging information from "libraries",
which are broadly the Google support libraries. I don't think it's
possible to strip debug information in this fine-grained manner using
Gradle. Second, I think the Gradle build might be including more code
than the moz.build configuration (see the follow-up patch removing
multidex support), but I can't determine what's actually different.
After APK compression, I see less than a 50kb regression in APK size
between Gradle and moz.build outputs, which I deem reasonable.
MozReview-Commit-ID: 4q4Zye2wnOF
--HG--
extra : rebase_source : dfc0f983f56ceb5907f9aafcb37d2ac63d50988b
This allows us the use of VectorDrawable's (which can be created by converting SVG files) in a
limited set of circumstances.
MozReview-Commit-ID: 4n4dXnZYn9W
--HG--
extra : amend_source : 8fbf2579260590a26ecd0112d6fce1055e929bd7
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
It's not obvious how to listen to individual errors in most cases, so
we just link to the reports for now. Progress!
MozReview-Commit-ID: 8nGRJdpzZnO
--HG--
extra : rebase_source : e81c9b29cb03c5ba73e793512525b5c9c68ab655
extra : amend_source : ce1e2368d43d37cab8fe41cd7a978342ad3e2ea6
