Delegate the action to WebViewProvider, by default it is no-op.
Bug: 36006397
Test: There is no implementation yet to test.
Change-Id: Ib5101d3669a92ae81cfb34cc5db607c374712a3d
Platform is now providing autofill feature. Disable WebView's simple
form data save feature for platform O and above.
Test: Removing the functionality and the test
Bug: 36869838
Change-Id: If6b9fc12edbe4146fca99d9c6ef8fde36d61f852
The ViewStructure typically represents a View, but it it can also be a virtual
view; in particular, WebView uses virtual views to represent HTML elements.
Although most of the properties of the HTML element maps to properties of
Android Views, some properties (such as 'name' and 'id' on <INPUT> fields)
don't, and those are crucial for autofilling web pages.
Rather than trying to artificially map these properties, it's better to create
a generic representation, for the following reasons:
1. Web standards move in a different velocity than Android APIs
2. Android APIs cannot be changed easily. Deprecated APIs continue to work,
and new added APIs don't work in older versions
3. The data used for autofill is opaque to the Framework - it's only relevant
to the node producers (like WebView) and consumers (Autofill services).
Also removed the setIdEntry() that was used for the same purpose.
Fixes: 36696757
Bug: 36718508
Test: VirtualContainerActivityTest with new checks pass
Change-Id: Ia626bd1f640b0b5861e81a5915504b95029874c9
Delegate the actions to WebViewProvider, by default they are no-ops.
Bug: 34780392
Test: Existing tests should be enough
Change-Id: Iefb1045b44a6e8cee5d1cc2c9b194b392d33f36d
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
Added setIdEntry() on ViewStructure and documented how WebView can map HTML
tags and attributes into ViewStructure.
Test: VirtualContainerActivityTest pass
Test: m update-api
Bug: 36056207
Change-Id: Idaee9612d2c1b1adac99f354c8f87137ee9ef877
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
Explain when a WebView implementation change can occur, and what happens
when it occurs.
Bug: 35764852
Test: None (java-doc change).
Change-Id: I2d2bcccc2f16bc911636373bb47c64d846f15b2d
This adds a Safe Browsing specific network error code for WebView. This
will be returned when we cancel page load because the end user has
clicked "Back to safety" on an interstitial page, the WebView is too
small to display a readable interstitial page, or other similar cases.
When this is used due to an unsafe subresource, the error passed to
WebViewClient#OnReceivedError() will be associated with that specific
resource, not the main frame.
Bug: 36007752
Test: N/A
Change-Id: I8b149a9d6e4ed113de0dd8ee051a2934af477128
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
