Bug:12492817
Add an experimental webview setting to developer options to enable
data reduction proxy.
Change-Id: Id73d7f5d655a7de18afff766c5c78209c92964ea
Introduces an API for configuring how the WebView behaves with
regard to referencing insecure content from a secure origin.
By default, apps targeting <= KK will allow mixed content. New apps
will block all insecure content.
Bug: 13948531
Change-Id: Ie773ee144e223f78b6449da0a8564192dd9c1c5d
Update WebViewClient to use it instead, and add a new public API,
onUnhandledInputEvent. Note that WebViewClients won't receive this
call back until WebView is updated to use it.
Bug: 14279909
Change-Id: Ied49791b469849f5c4cf4471f2b26c56b03f4961
Bug: 12983007
This is to add APIs for client certificates. Keep the APIs hidden
until finalizing the design.
Change-Id: I8a1e755e2c509cf821dff7c7df0ddd5270a5f79b
This will give us ability to add new webview featrues which requires permission without changing API during the WebView autoupdate.
Also deprecated geolocation permission related APIs.
BUG: 13699047
Change-Id: I6a557e11eb26c6ca236d44e75600e0b265fd791c
Bug: 13250097
The current print api for Webview does not allow setting the
print document name, so all documents show up using a hardcoded
name (which is visible to the user). Deprecate the current API
and provide a new one that allows setting the document name.
Change-Id: I7043b78e98f25bbc0e0ef33e1d6d3b0d34401e48
Bug 11291911
These deleted classes were previously public APIs and so need to remain
in the build (but hidden) in order to keep existing apps working.
(Partially reverts Change-Id: I02549a71104b35d86d99058c71f43e054730ec7d)
Change-Id: I28e53b056f41e66645136f5e18fba2ff55a65fe5
Delete all the Java classes used only by the old WebView implementation,
and also sections of common classes that were only needed for the old
WebView.
Bug: 10427705
Change-Id: I02549a71104b35d86d99058c71f43e054730ec7d
WebViewFactory remains as an abstraction layer, but will now always
creates Chromium WebView instances.
Bug: 10427705
Change-Id: I045e43eb35462567fecd29d04e7b61902baef547
Follow up to Change-Id: Ibc2496d5cef97b4685e001086f712fcaac231024 - this
method did not exist in klp-dev branch.
Change-Id: Ie64dd3b2357e0abefb4c7d3492f02d23d347f89f
So long as all usage is from a single thread per instance it is OK if
it's a non-main thread.
(But note that for apps targeting JB MR2 this was enforced to be the
main thread anyway).
Bug 10937207
Change-Id: Ibc2496d5cef97b4685e001086f712fcaac231024
Add a workaround to ensure that the WebViewDatabase and JniUtil can
still be initialized as side effect of making a CookieSyncManager
This was collateral damage from the fixes for Bug 10932261
Change-Id: If5ba65a7822d5b0afc14139dd84125058bf96897
Bug 10932261
Most of this flow exists purely to get the Context from
CookieSyncManager.createInstance over to WebViewDatabaseClassic. Make
that depenency more explicit (with a TODO to remove it) and this allows
a much simpler CookieSyncManager implementation for the normal case.
Note after this patch, CookieSyncManager.getInstance() is technically fine
to call without a prior call to createInstance, but retaining the
ordering requirement as a convenience for anyone developing on new OS
but still supporting the older versions.
(Note that CookieSyncManager instance is not required for correct
operation of either existing webview, so these changes only impact
the public API contract of object lifetimes, not the underlying
implementation)
Change-Id: I51fdd6622704f1c749277fee6df2f84ac4c704d2
Simple resolve: two new methods added to same class.
Conflicts:
core/java/android/webkit/WebViewFactoryProvider.java
Change-Id: Ic8b26f2a51279348b19a9c5b30d492f67d62ca81
