| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes a number of interconnected issues in memory safety
(MTE, GWP-ASan, nativeHeapZeroInit) runtime flags.
* Exported services use the hosting app UID to locate the process
definition, and fail 100% of the time. Use the defining app UID and
package name instead.
* Isolated services process name does not match the name in the defining
app manifest, because it includes a class name and an instance number.
Pass the defining process name in HostingRecord to address this.
* Exported service ApplicationInfo.packageName refers to the hosting
app, again. As a result, wrong compat feature overrides are applied.
This has been fixed before for AppZygote services; extend the fix to all
external services.
* Pass correct memory runtimeFlags to WebViewZygote. This is important
because both MTE and GWP-ASan have a one-way disable switch; they are
enabled in the Zygote and disabled in the apps that do not opt-in.
Passing 0 runtimeFlags to WebViewZygote (and AppZygote) makes it
impossible to enable these features later in their child processes.
This change moves runtimeFlags logic from ProcessList to os.Zygote to
make it available to WebViewZygote.
Bug: 208910418
Test: CtsTaggingHostTestCases
Test: atest in frameworks/base
Test: CtsWebkitTestCases
Test: manual install WebView with android:memtagMode tag
Change-Id: I232d35344f4cd34226ff11324421904b35251525
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We start WebViewZygote at boot time to ensure the first app to use
WebView doesn't have to wait, but we were not waiting for RELRO creation
to finish before doing so. Move the background task which starts the
zygote to WebViewUpdateServiceImpl and have it wait for the RELRO first
to ensure that we get the memory saving of RELRO sharing whenever
possible, instead of only when the timing happens to work out by chance.
Fixes: 130305037
Test: manual, check logs and relro sharing status after boot
Change-Id: I55c3f80b0db1dc82727b90c70f777618ca77a942
|
| |
|
|
|
|
|
|
|
|
| |
The WebView stub is only used in Monochrome configurations and is no
longer required with Trichrome. Remove the special case code used to
support it in the past.
Bug: 129470358
Test: atest CtsWebkitTestCases
Change-Id: Ieb11ae6698f370a1d601459e6253fc7dbe146014
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The webview zygote is shared for all users on the system, and so unlike
the app zygote, it can't use a single whitelisted UID range. For now,
clamp to the upper bound of the UID range, until we have a better idea.
This is still an improvement from the previous status quo, because it
will prevent setuid/setgid into system users.
Bug: 123597434
Test: builds, webview_zygote running
Change-Id: Ia975826ed5b1f20cabb46f60f5951723b1ba80c9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the "common" case where the WebView stub is not being used, have the
WebView zygote use the new APK preload path added for the app zygote,
which avoids duplicating logic from the framework to construct the
classpath. This allows the WebView implementation to use a static shared
library, which was not previously possible.
The old codepath is retained for now to keep the WebView stub working
when it's in use, as it requires the special mechanism to override the
classloader cache key, but this can be removed when we no longer require
the stub.
Bug: 110790153
Test: Manual verification of classloader cache state
Change-Id: Ie49e5810d570bae7bec0341753e6c50d081189b5
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit made the following changes to make the code conform to the
Frameworks style guide:
* Re-named variables
* Re-flowed code
* Organized includes
Topic: zygote-prefork
Test: make & flash & launch apps
Bug: 68253328
Change-Id: I9274b32f1f606f29f6eb3a1e5068ca18f607afe7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The application zygote can run untrusted user code; since it also
has the capability to change the uid/gid of the process, we need
to ensure that any changes to the uid and/or gid stay within the
range that we have allocated for this application zygote.
For application zygotes, we install the app_zygote seccomp
filter instead of the regular app filter; the only difference
between this filter and the app one is that it allows
setuid/setgid calls.
To further limit this, pass down the allocated UID range to the
Zygote itself, which in turn installs an additional seccomp
filter that restricts setuid/setgid calls to this range.
The actual calls into seccomp are commented out until the seccomp
changes are merged; to avoid catastrophe, this will leave the
regular app filter for the app_zygote, which is more restrictive
and doesn't allow setuid at all.
Bug: 111434506
Test: atest CtsSeccompHostTestCases passes
Change-Id: I112419629f5ee4774ccbf77e2b1cfa5ddcf77e73
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an application has requested isolated services to be spawned
from an app zygote, we need to spawn the app zygote itself, and then
ask it to fork an isolated service.
The application zygote currently only creates the class loader, and
doesn't do much else. We keep track of the isolated services that
use the app zygote, and when the last isolated service goes away,
we stop the app zygote itself (after a timeout).
The app zygote itself runs with the app's UID and under the app
seccomp filter. That last one is too restricted, so this currently
only works with SELinux disabled.
Future CLs will add an application callback for preloading.
Test: start multiple isolated services with useAppZygote="true",
verify app_zygote starts, services start as a child of
app_zygote. Stopping all services stops app_zygote as well.
Bug: 111434506
Change-Id: I10ee1d4bd148c9298974d434fbc5e5eccbec16cb
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts "Delay starting the webview_zygote until first use." but
instead wraps the start in a background task, to avoid blocking the
system server startup waiting for the zygote to be ready.
Bug: 73743583
Bug: 63749735
Bug: 74079433
Test: Verify webview_zygote already running after boot
Change-Id: Iacf968cc2d2857a92c6bacf4012dc88f098c6013
|
| |\
| |
| |
| |
| |
| |
| |
| | |
am: 99440a0ab8
am: 92697692b3
Change-Id: I4f810427f083d9b7874df7d90fc00a33967d9323
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
During boot, WebViewZygote.setMultiprocessEnabled() is called by the
WebView initialization logic. Starting the WebViewZygote here causes a
slowdown in the system_server boot process, so delay launching the
zygote until it is needed.
Previously the webview_zygote was launched by init, and merely
connecting to it in the boot process didn't have significant overhead.
Bug: 73743583
Bug: 63749735
Test: Boot a device, verify that webview_zygote process is not running.
Test: Launch "Third-party licenses" activity from Settings, and it
renders correctly via the WebView.
Change-Id: I1352a5df95e4a793ac64862c439ba2573ddd2d18
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that the WebView zygote is a child of the system zygote it has the
smae address space layout and can use the existing WebView native
library RELRO file.
Preload the native library using the RELRO file in the zygote, to share
this data with applications which are using WebView. This can save up to
1-2MB of dirty memory, replacing it with clean pages that are shared
with more processes and thus have a smaller impact on PSS.
Bug: 63749735
Test: CtsWebkitTests
Change-Id: I7ce670f5fcddae9e98631e21329840ef3ad52f9a
|
| |\|
| |
| |
| |
| |
| |
| |
| | |
zygote." am: 1c81aa6375 am: 486190f87b
am: 0dd7cf0bb3
Change-Id: I9468ec63053f35814ec45b18572966d8adc93f3e
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This uses the new ZygoteProcess.startChildZygote() method to launch the
webview_zygote, rather than having init start it. This will share more
memory between the app_process and the webview_zygote, reducing the
overall system footprint.
Bug: 63749735
Test: m
Test: Launch "Third-party licenses" activity from Settings, and it
renders correctly via the WebView.
Change-Id: I3e39cd8adb9c099c92ee34640428916d90cb2b8f
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The change to handling of the deprecated Apache HTTP library means that
the WebView implementation package might have a non-empty shared library
list. Make sure to fetch shared libraries when querying WebView
implementations, and take them into account when constructing both the
actual classpath to be used to precreate the classloader, and when
deciding what the cache key for the precreated classloader should be.
Change-Id: I5e1409358d935e1c9f325db434bc6d4ef8ead759
Merged-In: I5e1409358d935e1c9f325db434bc6d4ef8ead759
Fixes: 65574359
Test: launch anything that uses WebView
(cherry picked from commit 4fd8aa51e4de5a7c93841571e30ff10077d1b125)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The change to handling of the deprecated Apache HTTP library means that
the WebView implementation package might have a non-empty shared library
list. Make sure to fetch shared libraries when querying WebView
implementations, and take them into account when constructing both the
actual classpath to be used to precreate the classloader, and when
deciding what the cache key for the precreated classloader should be.
Change-Id: I5e1409358d935e1c9f325db434bc6d4ef8ead759
Fixes: 65574359
Test: launch anything that uses WebView
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Docs change only.
This wraps some Java literals (true, false, null) with {@code} blocks,
as per Android API guidelines.
This also addresses other presubmit errors:
* fix lines that have become too long
* fix broken import order and unused imports
Bug: 65213517
Test: make docs (and manually verify things look better)
Change-Id: Idc7fe28d40bea7bd1edcad539b75fa9c689b8d46
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We wait for both the system server and the WebView zygotes, using
infinite loops.
This CL adds a time-out to both these loops.
Bug: 37654329
Test: Boot device, disable Chrome, enable Chrome, then start a WebView
app.
Change-Id: I74397de3caf2b02ee403195aeb3beb2320a2240d
|
| |
|
|
|
|
|
|
|
|
|
| |
There is a time-window during which the WebViewZygote service has
started, but can't be connected to. To avoid crashing during this
time-window we add a retry-loop in this CL to explicitly initiate a
connection to the Zygote.
Bug: 36687066
Test: gts-tradefed run gts --module GtsWebViewHostTestCases
Change-Id: Ia58a3342cd4e149621ba6b4aaf926e7b53c06d8f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support loading a WebView package which specifies the name of a "donor"
that provides missing files. This allows a preinstalled stub WebView to
function by loading its code and assets from the preinstalled Monochrome
implementation, as long as the versions are close enough that the
manifest contents are compatible, which should be fine since
preinstalled versions will match.
To do this, we replace the stub's code paths in AppplicationInfo with
the donor's, so that all Java and native code and resources are loaded
from the donor APK at runtime instead of from the (mostly empty) stub.
To get the ClassLoader with the modified path cached as if it was the
regular path, we introduce a new "cacheKey" parameter in
ApplicationLoaders.
Bug: 21643067
Test: build "new" stub WebView upstream in chromium and test loading
Change-Id: I08cc9122b1c9def3e1206974f3e0e8973cca3419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the act of waiting for the WebView Zygote to start running,
and then connecting to it is run in a blocking way from
WebViewZygote.onWebViewProviderChanged(). This causes us to block large
parts of WebViewUpdateService for a long time whenever we change WebView
provider.
This CL moves the blocking code onto a background thread to unblock
WebViewUpdateService.
Bug: 35025131
Test: Ensure changing WebView provider from the WebView Implementation
Developer Setting is quick/responsive.
Test: Turn off WebView multi-process and ensure the WebView Zygote
Service is NOT started.
Test: Turn on WebView multi-process and ensure the WebView Zygote
Service is started.
Change-Id: I0b378a471491d40cbf027568ca317d6c080da4b2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a disconnect between the way webview created
classloader and the way makePaths decides if paths are
intended for bundled app.
This change moves decision making out of makePaths method
which allows WebViewZygote to pass correct argument and
have makePath omit java.library.path for libPaths
Bug: http://b/35426785
Test: manual
Change-Id: Iab5a18c0091d0193dafa750498eb00f378411ba0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The onWebViewProviderChanged callback can be entered from a binder thread,
rather than the system_server main thread. This could lead to races when
managing the webview_zygote.
Test: m
Test: Turn on Multiprocess WebView, install a new WebView provider, then
instantiate a new WebView. The new WebView should load (note that
this is racy so may require multiple attempts to test).
Bug: 21643067
Change-Id: I28512906c38e073d4e3d39a2f2b30dcbb50c85ff
|
| |
|
|
|
|
|
|
|
|
|
|
| |
WebViewZygote.
Test: m
Test: angler boots
Test: Turn on Multiprocess WebView in Developer Options and launch the WebView
Shell. The sandboxed_service parent process is the webview_zygote.
Bug: 21643067
Change-Id: I9dab548853372fd91f6bbe204cc8686ef2e94448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to create the classloader for the WebView in advance in the
zygote so that it can preload Java and native code for its children, but
the zygote can't talk to the package manager (so doesn't have a
PackageInfo for the APK) and also doesn't have an ActivityThread, so
constructing a LoadedApk is difficult.
Instead, we use the fact that ApplicationLoaders contains a
process-global cache of classloaders for APKs, and prepopulate a cache
entry without constructing a LoadedApk. This requires making
ApplicationLoaders public. To calculate the correct library paths from
the information the zygote has, we reuse the logic in LoadedApk (which
is already public, and just needs a small change to allow a null
ActivityThread when checking for instrumentation).
The other parameters for classloader creation (target SDK, bundled app,
etc) are hardcoded to usable values for the WebView's case. WebView
never needs to use any system libraries that aren't public so claiming
it's not bundled is fine even when that isn't actually true, and WebView
will always target the current platform API level.
Once the classloader is created, look up the factory class and call
preloadInZygote on it to give it a chance to preload the native library
and do other shared initialisation.
Bug: 21643067
Test: enable multiprocess WebView, examine librank output to see sharing
Change-Id: I696ead637e3f7382bcc58cfaf61eac5921862015
|
|
|
This adds a new init-spawned daemon, webview_zygote, that starts a JVM and
acts as a zygote process for WebView isolated_app services.
Test: m
Test: angler boots
Test: Turn on Settings>Developer>Multiprocess Webview. webview_zygote32 or
webview_zygote64 start (requires dependent CLs).
Bug: 21643067
Change-Id: Ida98bd04b4d77736b672b03af651c4eb97ce88c1
|
