In case we change our thinking on launching of downloaded files and start using
content:// URIs for that case as well, we already allow our FileProvider to
generate URIs for the whole file system using <root-path>. This is because users
can in principle move our download directory to an arbitrary location on the
file system as long as it is accessible to Firefox. However not all of these
locations (e.g. on a removable SD card) can be specified through the other
methods of specifying available files for a FileProvider, so only the <root-
path> option remains.
MozReview-Commit-ID: 2UStBlU4JsG
--HG--
extra : rebase_source : 2c1828e063c1b3e772ac20c415fd34d0da1c24a6
Now using the the TYPE_APPLICATION_OVERLAY window type to display alert windows for devices running on Android O.
MozReview-Commit-ID: 7pdquyowbsB
***
***
--HG--
extra : rebase_source : fc07c2c2a34fe53583ba59fc27a7a6f75f4a812b
Now using the the TYPE_APPLICATION_OVERLAY window type to display alert windows for devices running on Android O.
MozReview-Commit-ID: 7pdquyowbsB
***
--HG--
extra : rebase_source : c8ccb6d9c8bb681ee32d71b58c95f6efd933d34a
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : ce7c1585529e61491a0133633b976b27083c2372
extra : intermediate-source : f8b3e95f18e4082ab8404187508d09eadba8612e
extra : source : 8f1655752d43af33356d497d559888a967bbf6a0
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 9de77b6278bae76df3597bc2580bcedbf6d33075
extra : intermediate-source : c6e6fe49ecd2dd422878d80f57f1c89bf69eebff
extra : source : 8f1655752d43af33356d497d559888a967bbf6a0
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 4184f40d82bcd44c2bb380d1a8ab534967818af5
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 0547c79ecf404688972fc55658f09bdfce07b613
Remove related options, just use CustomTabs directly.
MozReview-Commit-ID: DdcMHnsfAU1
--HG--
extra : rebase_source : bc46d5d71d53acadc2cb0415790e9560eeda2c8a
Keep the value of SYSTEM_UI_FLAG_LIGHT_STATUS_BAR in window system ui status when show/hide fullscreen.
MozReview-Commit-ID: CnOsCFKuN65
--HG--
extra : rebase_source : b3a1afc6c5270730bc1d6c5d92bc9573c6eba8f9
extra : source : a0241dff71de29ba62b2b44c3e229df4a7de2d72
To test PWA, we must manually enable "manifest.install.enabled" in
about:config. This is not convenient for development or testing.
Now we try to add a preference option.
MozReview-Commit-ID: LbrNgZmAeUm
--HG--
extra : rebase_source : 0c2b3b2e9c05e962da870672c07ecb32202f1fd5
TLS_DHE_RSA_WITH_AES_128_CBC_SHA is no longer supported in API26+.
MozReview-Commit-ID: AtNf2xZh2Bz
--HG--
extra : rebase_source : fef7d2018e77a4a4a7594bf32de750c8fa39e2ea
remove the flag from GeckoPreferences as it is always true
MozReview-Commit-ID: J5bJwnaRFDa
--HG--
extra : rebase_source : 012ae9f1a220c7fd98f0b88c64dcbae4ad85b70c
Remove related options, just use CustomTabs directly.
MozReview-Commit-ID: DdcMHnsfAU1
--HG--
extra : rebase_source : bc081e180eca920979d8f4557751cf98c27c51de
On a CLOSED TREE
Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : source : 41d155de1019c0c6c693e2bf46bd1dd7b91d244a
extra : amend_source : 989f6ba2447a2b40d4bc6604241d7986c0d5dd00
Style varies across the tree, and this matters as we transition to
Python and moz.build. AppConstants.jsm already uses #ifdef, so this
is consistent with that.
MozReview-Commit-ID: Bal37lqlvjq
--HG--
extra : rebase_source : 8e4e459a9bdbc3a2cacde728f45e6edecc272e24
This flag wasn't used in the build system anyways. It was used to hide early builds of the
new Activity Stream UI. However this is now going to be controlled by Switchboard experiments.
MozReview-Commit-ID: Dfzw9YGgHkN
--HG--
extra : rebase_source : 2ecd3fb18a237f0de8e7d4752d69de568c062310
Added support for changing default browser by opening settings screen in API Levels >=24.
MozReview-Commit-ID: 5rxJm6hQQ4A
--HG--
extra : rebase_source : e8fc23bc658e216c04c27e10067c16abf2b0cd5c
This patch lays the groundwork for two things. First, it paves the
way for splitting AppConstants.java into two parts, a GeckoView part
and a Fennec part. This is necessary because the Makefile.in
preprocessing is not flexible enough to write two separate GeckoView
and Fennec constants files into different directories.
Second, this allows us to more flexibly generate the file contents.
Gradle has a way to get compile-time constants into Java code, which
we want to migrate to. The details don't matter right here, but this
paves the way to move from preprocessing to generating the
Gradle-style BuildConfig files while we continue to support both build
systems.
MozReview-Commit-ID: 2o8X99uLoaM
--HG--
extra : rebase_source : 54164d685b9c2b1342b1acba2913ce07b906a7d6
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
This allows artifact builds to load the new compressed native libraries correctly,
without requiring build config changes.
MozReview-Commit-ID: 3xZzoV3wFda
--HG--
extra : rebase_source : 5fffe02efc38af9024ca72654153deed3c4ef757
This will be used to enable the activity stream panel in place of the HomePager. We are
likely to migrate this to a switchboard flag in future once the new panel becomes
shippable (we are still investigating other distribution mechanisms, so it is entirely
possible this will completely change in future).
MozReview-Commit-ID: I9VSliO0IXE
--HG--
extra : rebase_source : 5c6578e41d7bc4849a7aa4a74c4be6cebc966231
I initially tested my code with a branch around the multidex dependency:
if (mozconfig.substs.MOZ_BUILD_MOBILE_ANDROID_WITH_GRADLE) {
compile ...multidex...
}
I removed it because it seemed unnecessary - the code shouldn't be
included if it's not referenced.
I tested:
* Locally with a build that did not exceed the method limit, pre-Lollipop
* On try, with fx-team
* On try, with beta
MozReview-Commit-ID: APaOdlKd3QF
--HG--
extra : rebase_source : 106d15f29db183387a77eb3cbc6968a7cac34286
See code comment (and related bug) for details.
MozReview-Commit-ID: EDzIBftjJRU
--HG--
extra : rebase_source : 94721323a4372010941dcce034093d3f0d1ac95c
