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
(cherry picked from commit 638d810099)
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
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
During a time window between the point at which a webview package
becomes updated and the WebViewUpdateService receiving an intent
declaring this action the WebViewUpdateService APIs will return a
PackageInfo pointing to an old and possibly removed WebView package.
This means that any paths that PackageInfo is referring to could have
been removed.
Currently, we set WebViewFactory.sPackageInfo using one of these APIs
and we might thus try to use deleted paths to to load WebView. This can
cause crashes, so instead fetch a fresh PackageInfo and assign
WebViewFactory.sPackageInfo to that.
Also early-out in loadWebViewNativeLibraryFromPackage if the current
package version doesn't match that of the one fetched from the
WebViewUpdateService.
Bug: 29381682
Change-Id: I2713ce2338a4a96c5317dcdbb363b424513088d5
This allows WebView to add itself to the ResourcesManager and
remain their even after configuration changes and multi-window
changes.
Bug:29112218
Change-Id: I2cb131ae2c61fb58c48babafdd46c1882be96aa9
There are cases in which the WebView Update Service can stop switching
WebView providers (if the update service is notified about relro
creations an incorrect number of times) and in those cases apps will
fail to load WebView.
In this CL we mitigate this problem by allowing apps to load WebView
even if the time-out is reached and we also decrease the time-out so
apps are less likely to ANR when waiting for the time-out.
This CL does not prevent the update service from ending up in a bad
state - so we will still end up crashing apps if the current WebView
implementation is uninstalled after relro creation fails.
Bug: 28860862
Change-Id: Ib6af3722e17a13db77ef34c37581a6a0e1d045bb
Update to javadoc comments saying that for apps targeting N and up
the geolocation api is only supported on secure origins.
On non-secure origins requests to geolocation api are automatically
denied without calling the corresponding
WebChromeClient#onGeolocationPermissionsShowPrompt method.
BUG: 28080869
Change-Id: I57726f7f3b3d38db0535f742b1f74c40c1f1ce8b
This callback was never used by WebView and anyone that overrides it
is going to just be broken since we never actually call into it from
the method that WebView does call. Furthermore, the WebView team has
decided that the API has too many complications to ever implement,
the most notable of which is that MotionEvents tend to come in
streams that would need to be buffered in order to detect the event
before it can be determined whether they were handled or not which
means that any uses of the API are inevitably going to be janky
experiences.
Bug: 14279909
Change-Id: I068601ce947bccacabfe55b86b06005449b65bcf
This reverts commit ee34ef1633.
This API is no longer needed by webview since 51.0.2704.22.
So remove this API. Note that this system API has never shipped
so it's ok to simply remove it.
Original description:
> Expose setDrawGLFunctionDetachedCallback to webview
>
> Add WebViewDelegate.setDrawGLFunctionDetachedCallback system API that's
> used for webview to receive the functor detach callback.
>
> BUG: 27709981
> Change-Id: Ie6b5e445c0090a181f94fcd2ec1ea77095c9cb03
BUG: 27709981
Change-Id: I9920dbedc6a280b4a19a8715832c4d2f64a7a7be
Prevent *any* WebView provider packages to be downgraded lower than MonoChrome
Stable on the system image.
Assuming that all (and future) WebView provider packages follow the same
versionCode scheme, we can compare the subsection of Chromium versionCode that
contains branch number, which is done by ignoring the least significant 5
digits.
Note this CL is a follow-up to go/ag/895502.
BUG: 27469181
Change-Id: Iffe3c4b7f912d48c034f107079e065e54130713f
Now that invokeDrawGlFunctor doesn't use the View anymore, and just
calls a static method on ViewRootImpl. In particular this is required
since invokeDrwaGlFunctor need to still function for views that already
detached.
BUG: 27709981
Change-Id: I2c8c8f4a6943f7eec773265ca709349c5ce0be54
To ensure that the package we are using to load WebView is a valid
provider we need to verify this before loading WebView - not only when
choosing what package to use.
Bug: 27900925
Change-Id: If57ca32a7a3fa08735a3b8ea9ed268c1bb1b8ede
To make the WebViewUpdateService testable we create a new implementation
class that contains the implementation for the actual service. This
implementation can then be tested.
Bug: 27635535
Change-Id: I45c25c71375cc86a04c649a845016d2e7b105a7a
Move more code from WebViewUpdateService to utility classes (methods
handling settings and uninstalling/enabling/disabling packages) to be
overridden during tests.
Also rename system utility class.
Bug: 27635535
Change-Id: If49999fba4fd0962f103f389898fa5ddf19365bd
Add WebViewDelegate.setDrawGLFunctionDetachedCallback system API that's
used for webview to receive the functor detach callback.
BUG: 27709981
Change-Id: Ie6b5e445c0090a181f94fcd2ec1ea77095c9cb03
Instead of using reflection in XTS tests we add some system-apis to
enable fetching information about webview packages.
Bug: 26381867
Change-Id: If983a01b6855e4a4c08ef0b5873304918d499b76
The WebViewProviderInfo should now be ready to be added as an API to be
fetched from XTS tests (to avoid using reflection).
Move the logic for validation, signature checking and package info
fetching out of WebViewProviderInfo so that we can mock the coupling
between that logic and the system (e.g. the package manager).
Note: with this patch we stop caching valid webview packages in the
update service (we would still refetch them anyway when anything
important happened).
Bug: 27635535
Bug: 27736084
Change-Id: Ia455202d2fd5bc4e03dce0fd917d262bf942d1a3
To make the WebView preparation mechanism testable we add a utility
interface that can be overridden during a test to avoid calling the
Android framework and to provide custom WebView packages.
With this change we also split some of the code from the WebViewFactory
(code unrelated to WebView loading) into a separate utility class.
Bug: 27635535
Change-Id: I265ecd42b24ad5383637e125b3654ff339c9df9c
The replacing-logic tries to handle packages being uninstalled while
being replaced. This can't be handled through listening to
package-replaced intents since those can be delivered long after the
actual problem occurs.
Bug: 27605997
Change-Id: Iba8e546a5bba1ceb6226d4edb71db088c81ae1a9
Use the namespace corresponding to the WebView APK's classloader to load
the native library. This prevents the library from being loaded twice in
certain situations.
Bug: 27189432
Change-Id: Ia232bf13a2a04b18214af4fecde68fafc534983f
Loading WebView should not cause any StrictMode violations since app
developers using WebView with StrictMode turned on would have to turn
off StrictMode violations at the point at which they create a new
WebView.
Bug: 27240115
Change-Id: Ia2f5565be6f36560bc9881624faf6645bc2c8575
