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
Using a WebView package targeting a release before O as WebView provider
on O will cause crashes (because of incompatibility issues), this CL
makes us interpret a package targeting a pre-O release as being invalid
on O.
Also remove the code that lets us fall back to loading the old
WebViewChromiumFactoryProvider (pre-O) class.
Bug: 34773740
Bug: 34180497
Test: Ensure WebView provider with targetSdkVersion="O" shows up in the
WebView Implementation Dev Setting, ensure targetSdkVersion=25 doesn't
show up.
Test: Add WVUS unit test to ensure a packages with targetSdkVersion < 26
are considered invalid, and > 26 are valid. Run WVUS unit tests.
Change-Id: I4d80d46019e2522bc3fc6068712d28eedb31fcce
To make backward compatible, kills application when render process
is killed by system.
Bug: 30824898
Test: No test, this is document revision.
Change-Id: I12862ee9ed1986ec274fe627782542e8d8414856
Allow the WebView implementation to call isMultiProcessEnabled via the
delegate, so that it doesn't have to fetch and interpret the value of
the system setting itself.
Bug: 21643067
Test: manual (requires modifications to chromium to call)
Change-Id: I1ef2b7ea0054c606965040e02034c938d5e6464c
MultiProcess WebView will use a Service to start a separate process (the
renderer process). This Service can only be started if the WebView
package is enabled for the current user. To ensure that the current
WebView package is usable by all users on a single device we now only
use a WebView package as WebView implementation if that package is
enabled and installed for all user on the device. This also means that
the WebView-fallback mechanism will trigger when disabling the primary
WebView package for any user (not just the system user).
Also add multi-user unit tests to cover this new change.
Bug: 32894152
Test: run unit tests in WebViewUpdateServiceTest
Test: ensure the standalone WebView package becomes enabled (for all
device users) when disabling Chrome for a secondary user.
Test: load WebView (both using Monochrome, and using the standalone
WebView).
Change-Id: Iad3fc48aa50273062c2f29ae48a343c2dea38116
The renderer importance API is used to specify how important
out-of-process WebView renderer services are for the purposes of OOM
killing and scheduling with respect to the binding application.
This allows an application to - for example - specify that renderers can
be killed while the application is not in the foreground, thus cleaning
up additional resources.
Bug: 30824898
Test: Tests await Chromium change.
Change-Id: I6dca3d427d6cdb5cb7e0be6f7fb8ece64bd24af9
Instead of letting DevelopmentSettings manage the setting directly and
observing the changes from WebViewUpdateService, have the update service
manage the setting and just expose IPCs for the settings app to use to
get/set the setting. This means we can set a more flexible policy for
whether multiprocess is enabled by default and change it without
touching the settings code, though for now this CL does not change the
behaviour and is just a refactoring.
Bug: 21643067
Test: Toggle multiprocess WebView in developer settings
Change-Id: I3057c09d99f5f6f472a5195a8e14e9164ea5733a
- Explicitly split View methods into Assist and AutoFill methods, rather
than use an overloaded method that takes flags.
- Simarly, renamed ASSIST_FLAG_SANITIZED_TEXT and
ASSIST_FLAG_NON_SANITIZED_TEXT flags to
AUTO_FILL_FLAG_TYPE_FILL and AUTO_FILL_FLAG_TYPE_SAVE respectively.
- Created a AutoFillUI class to host the auto-fill bar and other UI
affordances.
- Moved the temporary notifications to AutoFillUI (eventually that
class will host the real UI).
- Moved FillData to android.app.view.autofill package.
- Split IAutoFillCallback in 2 (IAutoFillAppCallback and
IAutoFillServerCallback, residing at the app and system_server
respectively), so service cannot fill the app directly (which lets
the framework control the UI).
- Moved assist's IResultReceiver to AutoFillServiceImpl so
system_server can act as a mediator between the AutoFillService
implementation and the app being auto-filled.
- Replaced FillData and FillableInputFields by a bunch of new objects:
- FillResponse contains a group of Datasets, each representing
different values
that can be used to auto-fill an activity (for example, different
user accounts), optional id of fields the service is interested
to save, and an optional bundle for service-side extras.
- Dataset contains a name, Fields, and an optional bundle for
service-side extras.
- Fields contain an AutoFillId (parcelable) and a value (Bundle)
- Changed the temporary notifications to emulate the new workflow:
- Initial notification requests the auto-fill data but do not
auto-fill.
- Once service calls back, a new notification is shown with the
results.
- Then if the user selects a dataset, the activity is auto-filled
with it.
- It also shows a notification to emulate what can be saved.
- Created an VirtualViewDelegate for views that uses a virtual
hierarchy for assist data.
- Added new methods on ViewStructure to add children with virtual ids.
- Added 2 methods on View to support auto-fill:
- autoFill(Bundle) to auto-fill the view.
- getAutoFillType() to return how the view can be auto-filled.
- AutoFillType defines the input fields that support auto-fill:
- Text fields (like EditText)
- Toggle fields (like CheckBox)
- Lists (like RadioGroup)
- AutoFillType can also have a sub-type representing its semantic (for
now only text fields have it, and it's the same as getInputType()).
- etc :-)
Bug: 31001899
Test: manual verification
Change-Id: I2dd2fdedcb3ecd1e4403f9c32fa644cb914e186f
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
Bug: 30824898
Test: There is no test yet, this patch just add the defintion of API,
and make it easy to work on chromium side.
Change-Id: I7fdaf894f18cc8bad8e84465e4a0390b22f8bba8
The AutoFill Framework uses the same AssitStructure provided by the Assist API
and so far it was using the same methods as well, both internally and externally
(public API).
Sharing that internal code internally is fine, but the public APIs must distinguish between the 2 cases so they can fill the assist structures accordingly (although the initial implementation still shares the same logic).
This CL also splits the original 'auto-fill' request in 2 types of requests,
which are set by View flags:
- ASSIST_FLAG_SANITIZED_TEXT
- ASSIST_FLAG_NON_SANITIZED_TEXT
It also added new methods and callbacks to handle save requests.
Bug: 31001899
Test: manual verification
Change-Id: I4eb09099dc19a43cb7e053e64d939aed3704b410
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
Update the documentation to clarify that WebView calls methods of the
InputConnection on a separate thread than the UI thread. This is,
in some sense, similar to shouldInterceptRequest. The methods
that override InputConnection methods should be careful about thread
restrictions and concurrency when calling other methods or accessing
shared members.
Test: Document update. Verified manually.
Change-Id: Ida76cd5dcc683092c05947c3044d848d0a249547
Now that WebView can be loaded from one out of a set of packages we
provide an API for fetching information about this package.
Such API is especially useful for debugging crashes.
Bug: 30597460
Change-Id: I13dd746f7efcf2917b517053010b73ea35241325
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
Add getWebViewClient and getWebChromeClient to WebView and WebViewProvider.
These APIs both return null if the client is not yet set.
Change-Id: I22044713a43ab09a9a5a63138247bfecb60f2522
Test: N/A
Bug: 31843416
Fix various spelling errors, change spellings/capitalizations to be more
consistent with the rest of the documentation, and delete extra words.
Change-Id: I63eb85c0594d53d9e91836507209771094ff0f33
Test: N/A
This gives the implementation the flexibility to choose different
provider instances. Fallback to constructor if static initializer
factory method doesn't exist.
Change-Id: I72fa0c51c64d0dbdeb6234a0ab4fdd0a389b09fc
ART uses the class object's embedded monitor to protect class
initialization - the same monitor used by "synchronized" applied to
static methods. This can cause deadlock in extremely rare cases of
preemption during WebView code loading.
Remove synchronized from all static methods in WebView, to avoid this
deadlock. In most cases the synchronized is simply unnecessary in the
Chromium-based WebView implementation; in CookieSyncManager we instead
use a separately allocated Lock object to preserve thread safety.
Bug: 27417671
Change-Id: I13049f23fc984b77a3f4c203a5c698858c64abfe
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
