This patch converts `GeckoChildProcessServices.java` into a jinja template.
We also add an overlay generated from a jinja template for `AndroidManifest.xml`
that provides the definitions for content process services.
Note that even though Gradle supports simple substitution of variables in
manifests, I opted not to use that functionality. Since we need the more
powerful template functionality that jinja provides, I felt that having multiple
ways to substitute information into the manifest would be confusing, so we're
using jinja exclusively.
Differential Revision: https://phabricator.services.mozilla.com/D82578
* We add a config option for setting the number of content services;
* We add a config option to indicate whether content services should be isolated.
This one is just a `project_flag` since it doesn't really need the ability to
be overridden; it's something whose default we would want to flip when the
time comes;
* We set a dependency so that mobile/android/base/pre-export is executed;
* We add the `gen_from_jinja.py` script which is mostly just a dumb shim that
takes the input template and the config arguments, instantiates jinja,
generates the final output, and dumps it to the output fd;
* We add the requisite `moz.build` statements to generate the manifest overlay
and the service definitions;
* We update `build.gradle` so that Gradle knows to look for the generated files
when building the apk.
Differential Revision: https://phabricator.services.mozilla.com/D82577
This patch converts `GeckoChildProcessServices.java` into a jinja template.
We also add an overlay generated from a jinja template for `AndroidManifest.xml`
that provides the definitions for content process services.
Note that even though Gradle supports simple substitution of variables in
manifests, I opted not to use that functionality. Since we need the more
powerful template functionality that jinja provides, I felt that having multiple
ways to substitute information into the manifest would be confusing, so we're
using jinja exclusively.
Differential Revision: https://phabricator.services.mozilla.com/D82578
* We add a config option for setting the number of content services;
* We add a config option to indicate whether content services should be isolated.
This one is just a `project_flag` since it doesn't really need the ability to
be overridden; it's something whose default we would want to flip when the
time comes;
* We set a dependency so that mobile/android/base/pre-export is executed;
* We add the `gen_from_jinja.py` script which is mostly just a dumb shim that
takes the input template and the config arguments, instantiates jinja,
generates the final output, and dumps it to the output fd;
* We add the requisite `moz.build` statements to generate the manifest overlay
and the service definitions;
* We update `build.gradle` so that Gradle knows to look for the generated files
when building the apk.
Differential Revision: https://phabricator.services.mozilla.com/D82577
Gecko already broadcasts `memory-pressure` events from the parent process down
to its content processes, but that excludes any case where Android is calling
`Service.onTrimMemory` directly on the content processes.
This patch handles `onTrimMemory` and translates its requests into
`memory-pressure` events that various Gecko components (including the GC)
listen for. We only handle the severity levels for background processes for now,
as memory cleanup for background processes is currently the most pressing issue
(and I'm not even sure what we could do for foreground memory cleanup without
janking anything).
The argument to `memory-pressure` should depend on the severity of the request
as well as the frequency of pressure events. In particular:
* The most severe request, `TRIM_MEMORY_COMPLETE`, is a last-ditch effort to
reduce memory. This should trigger a full GC, so we use `low-memory` here.
* "New" requests, where "new" is defined as an event that was triggered in
excess of 10 seconds since the previous "new" event, also gets a full GC, so we
use `low-memory` here as well.
* Additional requests that do not fall under either of the above criteria
receive the `low-memory-ongoing` event, which omits a full GC. The idea here
is that, when low memory notifications occur in rapid succession, repeatedly
doing full GCs over and over is just going to hang the Gecko thread and not
result in any notable improvement.
Differential Revision: https://phabricator.services.mozilla.com/D101406
This patch adds `queryString`, `queryBoolean`, `queryVoid` and `queryBundle` to
`EventDispatcher` in place of `dispatch(type, message, callback)`.
These `query*` methods returns a `GeckoResult` which can be manipulated using
`GeckoResult.map`.
Differential Revision: https://phabricator.services.mozilla.com/D96951
Now, Fennec theme files (mobile/android/themes/core) are unused and
GV's files are in mobile/android/themes/geckoview.
So we can remove Fennec theme files.
Differential Revision: https://phabricator.services.mozilla.com/D100755
Add ACCESS_WIFI_STATE to the gve manifest, same as androidTest.
Remove ACCESS_WIFI_STATE from the list of pm grants, since it is not of
type dangerous.
Differential Revision: https://phabricator.services.mozilla.com/D100727
I want to start with 3 so that we initially get a good look at how things run
with multiple processes, but when we easily hit the limit. We'll increase to
our final process count in a future bug.
Differential Revision: https://phabricator.services.mozilla.com/D94884
`devicePrompt.properties` ... Presentation API UI frontend for Fennec.
`phishing.dtd` ... Safe browsing API UI on Fennec.
`pippki.properties` ... NSS Dialog UI such as importing certificate of Fennec.
`sync.properties` ... Firefox sync UI on Fennec.
`webcompatReporter.properties` - Web compat addon on Fennec
`passwordmgr.properties` still be referenced from `LoginManagerPrompter.jsm`.
So, I'm not sure we should keep this.
Differential Revision: https://phabricator.services.mozilla.com/D99798
Add the permission to the geckoview manifest, as previously attempted. Also disable failing tests
to enable a green test run. Add permission to adb.py grants list for good measure.
Differential Revision: https://phabricator.services.mozilla.com/D98809
Currently, the gamepad code uses a uint32_t as a handle and does some trickery
with it by trying to create a unique ID and adding an offset to it for VR code.
This can (and has) led to errors where the developer forgets to perform the
arithmetic and sends the wrong number to the wrong manager.
This change created a strongly-typed handle that remembers which service it
belongs to. This should eliminate such accidents.
Differential Revision: https://phabricator.services.mozilla.com/D96273