Removed FHR client id migration code on the Android side.
MozReview-Commit-ID: X9QKtbh6r3
--HG--
extra : rebase_source : f5587789f6980aecc4309dc329eb051650ad4c6f
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
The same situation applies when restoring recently closed tabs. In this case, we
can also display a nicer title for those lazily-loaded tabs by making use of the
session store data.
MozReview-Commit-ID: AJiEkTEVAUz
--HG--
extra : rebase_source : a36e0bb0cd4e3e8d62368f1ee5f51ad0c080027c
Processing the contents of the tab queue will open a potentially large number of
tabs. To avoid overloading the device we should therefore only load the new
foreground tab and leave the rest to be loaded on demand, when the user selects
one of them.
MozReview-Commit-ID: 9cjoLPRscRl
--HG--
extra : rebase_source : b32f46507156cf38460cd89a8cde09a8f7a51505
We'd like to install the NDK through the Android SDK manager. But we
can't pin versions of the NDK with the SDK manager, and so Google
can silently upgrade the NDK on us. Since that is undesirable, this is
the next best thing.
With the toolchain task in hand, we can make all the relevant tasks
depend on the toolchain task and remove the download of the NDK from
tooltool as well.
Longer term, the MenuItemInfo handling needs to be moved out of BrowserApp in
order to solve bug 1414084 [1], but the easier short term solution is to just
save the cached menu data via the savedInstanceState. This means that
MenuItemInfo and friends have to be made parcelable.
[1] Because of GeckoView, add-ons may load (and attempt to add menu items) while
BrowserApp isn't even alive.
MozReview-Commit-ID: HzPe7ZKbJOj
--HG--
extra : rebase_source : a38d3119c863ca48fdbd068b634c76681a3bfd34
Since custom tabs and PWAs were moved to GeckoView, we're down to one
GeckoApp-based activity again.
MozReview-Commit-ID: 1zO6JTDptpp
--HG--
extra : rebase_source : 1e65963fddeb53a3522422a902bdfbb3408a251a
The advantage of doing this per-variant is that we can really separate
the 'local' behaviour (re-generate via re-entrant |mach build|
invocations) from the 'official' behaviour (never re-generate via
re-entrance).
This also uses new Android-Gradle plugin 3.0+ APIs to integrate the
generated resources and Java code.
MozReview-Commit-ID: 4pd2iw1nJSb
--HG--
extra : rebase_source : 205080d3822f59bcdd5d3b44de2898ff775f5746
extra : source : 730a70767743b74a7e3a1fcf4018540edfdf30a3
There were a few API changes, mostly around explicitly creating
Services/Activities/ContentProvider instances, but they were pretty
easy to address.
Sadly, Robolectric doesn't really work with the new aapt2 processing
in Android-Gradle plugin 3.0+ -- see in particular
https://github.com/robolectric/robolectric/issues/3333#issuecomment-324300418
-- so we have to opt-out of the new implementation for now. Hopefully
plugin 3.1+ will address these issues, which are widespread.
MozReview-Commit-ID: dlbd32kMs6
--HG--
extra : rebase_source : fe30729161e5dc91ea9173f9b7aaa9135d096791
extra : source : 690e265c684ce70ecb89355314fd1574bb421f0b
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 22008e9333b15c594ce26c2a52f67396d6e3ab84
extra : source : f918500d9cf5112b70bc8e0a120df435b02252b7
This sketches the flavor dimensions. The important ones are
`audience` and `geckoBinaries`, which I think simplify the situation
greatly. Coupled with Bug 1417232 centralizing most everything in
`mobile/android/gradle.configure`, the Gradle configuration shouldn't
be so hard to evolve.
MozReview-Commit-ID: DILjVrnLA3F
--HG--
extra : rebase_source : a4ea96a49308f457a406716662d9b64d4ba749fe
extra : source : cec2b8828cc8800fa269d290ce38ea82c454b445
This was added for the Remote Tabs panel in Bug 785199. That code has
now morphed into the combined history panel, which uses a
RecyclerView.
MozReview-Commit-ID: J6KsVCn8mzh
--HG--
extra : rebase_source : 2d8a43b6697367f9fec1db760dd1e36ca12e31d0
extra : source : 2b37201606f5a921d91339e2c8a2ec86885b68e8
Newer versions of Robolectric seem to have different semantics about
clearing disk caches, so this is necessary. But for older versions,
it shouldn't hurt, and is slightly more clear than relying on an
implicit clear.
MozReview-Commit-ID: LRcaEPasXj8
--HG--
extra : rebase_source : 4d6bb4916cde61f198004661bed58025e91ffa9c
extra : source : 373c9a71d9451498462594b302b4fe2648431fef
No idea what is going on with this hierarchy, but this isn't used and
isn't helping anything.
MozReview-Commit-ID: Ir3LxLYHR6M
--HG--
extra : rebase_source : f1726d37fa285de1042fed76a722f941380cbf63
extra : source : 3dc3beab95f83b2f08ff9ff305fdd4b85cc05d9d
This is just wrong.
MozReview-Commit-ID: EBtKTD07aNu
--HG--
rename : mobile/android/base/resources/values-v17/themes.xml => mobile/android/app/src/main/res/values-v17/themes.xml
extra : rebase_source : c6e58c6be966dd8ace6aa796b5a5e6000ee9c65e
extra : source : 22a861db1573364916ab2c5b6d0c6321ba08ff55
The skin used on Firefox for Android doesn't style directory listing, hence we
fall back to using the default icon from gre/res/html. As of bug 863246, this
location is no longer accessible from content as a resource://, hence the file
needs moving into the special content-accessible directory.
MozReview-Commit-ID: obtefafqul
--HG--
extra : rebase_source : 0227487abb4914a11f5749c493d215a1fec45e46
This modifies mediaCaptureWindowState() to say whether a camera or microphone is
actively captured or not. Note that this is not the same as the device being
on or off. If we disallow a device from being off while disabled, we still
notify chrome that we're not actively capturing.
MozReview-Commit-ID: B1taormqc3j
--HG--
extra : rebase_source : 292d323c4b9711cc242170f5c5c139bb87658c44
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
Right now, we only expect classes.dex, and even --with-gradle we copy
it out of $topobjdir/mobile/android/base. This commit changes that
for --with-gradle: we only take classes.dex from the given .ap_ file,
and we also handle multiple classesN.dex files (for future multi-dex
support). The moz.build system stays the same.
This avoids an issue with newer Android-Gradle plugins, where the
classes.dex produced could be either in dex/ or in dexMerger/,
depending on whether any external libraries needed merging. By
extracting classes.dex from the .ap_ file, we don't need to know what
Gradle build steps actually occur.
The classes.dex in the package-manifest.in has been irrelevant since
Bug 1260241.
MozReview-Commit-ID: FozKwjTcMzU
--HG--
extra : rebase_source : 62b18c7ffe596be73cec4c9565333eac222b018e
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This listens for "DOMWindowFocus" and calls onFocusRequest in the GeckoSession ContentListener whenever it is received, and implements onFocusRequest for custom tabs and PWAs.
It was only used in the 55 Nightly and never meant to stay around.
MozReview-Commit-ID: JDJr9WC4V5M
--HG--
extra : rebase_source : af52eb24c4d599651a4cbde7b00049272448c9e6
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 17a25d2a15868f3661248a06b9048741e5a1dca5
extra : intermediate-source : d4d42899e5cd4255df3bfb4332532936e42ebf43
extra : source : be888fa125dc1948fc073ed69aa8116f47e22877
Besides adding a new ping builder for 'crash' type pings this patch modifies
part of the Java telemetry to accomodate for it: a new store has been added
for holding crash pings and the URL used to submit has been updated to pass
the 'v' parameter (crash pings are in the telemetry version 4 format).
MozReview-Commit-ID: CZzw7xv6YoS
--HG--
extra : source : 1089cb510d173dee2fe6d0e1a172af46808d52fa
Vary the 'Share [...]' label depending on the actual use of the <video> tag, as
is done for the 'Save [...]' label.
MozReview-Commit-ID: Ga6RqV5dCby
--HG--
extra : rebase_source : 8a146d032d4fc9185fd197bb2ad737e62a17cb5b
If we have to forward a download that we cannot handle ourselves to the Android
download manager, then the speculative download started by Firefox needs to be
aborted no matter whether forwarding succeeded or not.
MozReview-Commit-ID: B6zCk28ci1P
--HG--
extra : rebase_source : 1a051afa7eab3426d397e362bc5d26a6a7886917
This also verifies that we have Google Play Services (via
MOZ_NATIVE_DEVICES=1) if we ask to build with GCM. This was just an
oversight earlier.
MozReview-Commit-ID: BvJi7Sfo4pu
--HG--
extra : rebase_source : c02766104281a895ab57e58079a1f651e1b9f832
extra : intermediate-source : 78828bf781d737b03c249de3dd41dc9edec788fc
extra : source : 44bcb609e721598135a19bf41ba7ff94f3051553
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
Dispose the native call queue when disposing a window object, so we
don't end up with stale calls in the queue that can cause crashes.
MozReview-Commit-ID: J1HNOXKAX6E
--HG--
extra : rebase_source : 9a3ec940c19513d29c692d4e550fa3fd046d73f9