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
Since the WebView loading mechanism is global - it doesn't differ
between different users, a user for which the current WebView provider
is uninstalled won't be able to fetch any information about the current
provider without passing a certain flag (MATCH_UNINSTALLED_PACKAGES) to
the package manager.
Bug: 26677081
Change-Id: Id1b86164bb22fc7285d292da1b1115fb25e4d226
Bug: 22665752
Token binding protocol is the next generation channel-ID protocol,
currently it is a draft in IETF
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-03
Add the api as a system api (will be public once the draft finalizes)
Change-Id: If971cc7e6d14f15c778b9b027df9fc48dac0160c
Catch a bunch of simple cases where the PackageManager flags are
obvious. Add the ability to use the MATCH_SYSTEM_ONLY flag on
PackageInfo and ApplicationInfo queries.
Re-examine recent tasks after a user is unlocked, since some of the
activities may now be available and runnable.
Bug: 26471205, 26253870
Change-Id: I989d9f8409070e5cae13202b47e2c7de85bf4a5b
Ever since the refactoring of WebViewFactory - to support using one out
of a list of WebViewProviders - we cover less of the loading code with
traces, this CL fixes this.
Bug: 26409579
Change-Id: I9d74321806037ea34a5ace8fc75b07ca771ab7d9
Add an XML tag declaring whether a package can be used without
explicitly being chosen by the user (it is available-by-default).
Change the WebView loading logic to either
1. load a user-chosen and enabled package or
2. load an enabled and available-by-default package or
3. any package that is valid
Bug: 26400585
Change-Id: I8de253c1687e3cc7961184c2d770d4e385d6187a
If one of the signatures match the package signature the package is
considered valid. This makes it possible to match signatures in user
builds for both signed and unsigned builds.
Bug: 26220882
Change-Id: Ie2e7567bf518d4859d68b5fdf5b9833fcdaa7670
Make it possible to change WebView provider (through a Developer
setting) and kill all apps using the old provider.
This includes checking the signatures of the WebView providers to make
sure they are valid.
Now that we can change WebView provider through a setting it is possible
to change provider while some provider is being updated. Because of this
we now keep track of which provider should be in use in
WebViewUpdateService to make sure we use the correct provider at all
times.
We now also read WebView package meta data (name, package name, and
signature) from a separate xml file.
Main bug: crbug.com/546185
Bug: 25338573
Change-Id: I660fd1a40a5388f6569a06a7f0d029e8ff65945a
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
