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
This patch makes it possible to declare a WebView package as a fallback
which means that the package will be enabled iff there exist no other
valid and enabled (and available-by-default) webview packages.
The enabled-state of a fallback package is updated at boot and if a
webview package is changed (it it's been up/downgraded or has had its
enabled-state changed).
This patch also adds 'webviewupdate' shell commands for enabling and
disabling this mechanism.
Bug: 26375524, 26375860
Change-Id: I151915e5d6d932697dab10aeb593687e6b9c817e
Bug: 26361557
When the embedded app requests a ignore of a client cert request,
webview does not cache the response of the app. However, underlying
layers could. Clarify the document.
Change-Id: I43e6a4c91727f71c88ca69e1334f64de9f66905a
The current WebView provider is not user-specific and should therefore
be stored as a Global rather than a Secure setting.
Also do some code cleaning including a fix in WebViewProviderInfo to
always fetch up-to-date information about whether a webview
implementation package is enabled.
Bug: 27142972
Change-Id: I4d4b8fca775e97980fb5c34313be6d82472e7d33
Bug: 22665752
The user of the API can provide different algorithms for key generation.
The API should also provide information about which algorithm is
used for generating the key.
Change-Id: I1d671ba351ca495b031b159132f33291a4f33aac
Service Workers are not tied to WebView instances so currently
there is no mechanism to capture callbacks originating from
within Service Workers.
This patch adds the necessary classes to capture callbacks
and allows to set settings specifically for Service Workers.
The main idea is that to control service workers the embedding
app would obtain an instance of ServiceWorkerController using
ServiceWorkerController.getInstance() first. After that it would
be able to set a custom ServiceWorkerClient and change
ServiceWorkerWebSettings via the controller object.
BUG: 22709088
Change-Id: I0eb17be46b767851676b77a94757771611fa3a1b
