[WebView Support Library] Ensure the reflection calls we use to initiate the support library are supported on most major devices/Android versions. |
|||
Issue descriptionTo intialize WebView Support Library objects we will have to use some reflection - we should ensure the methods/fields we need to access exist on most major devices / OEM versions. For the original support library approach (providing all WebView APIs) I think we just need the WebView classloader - which we can fetch through a call to WebViewFactory.getProvider(), which is a SystemApi since API level 22. For the alternative WebView approach (new API), we need the WebView classloader and a reference to the existing WebViewProvider (to be able to augment an existing WebView instance). We might need access to other android.webkit object as well (if we want to augment their APIs).
,
Oct 24 2017
Scoping this out: WebViewFactory.getProvider() is a package-private API that is not a public/systemApi for Android, so we should ensure devices support this API. I would guess that if we want to use this API we should ideally make it public, but at least a SystemApi - given that it's not something an app would want to touch it shouldn't be public though.. Through this API we can fetch the WebViewFactoryProvider (to gain access to any static objects). I believe this API is all we need for other kinds of managers/services as well, e.g. CookieManager and ServiceWorkerController, since we can fetch the existing manager/controller/service through the WebViewChromiumFactoryProvider. The only case this wouldn't be true for is a case in which the app creates its own new object, e.g. new WebView(), rather than fetching an existing singleton from the WebViewFactoryProvider. Do we let apps create any other android.webkit related objects than WebViews (except callback-clients like WebViewClient) ? We can get the WebViewProvider for a specific WebView object through the @SystemApi WebView.getWebViewProvider() method. Given that this is a system API it should be available on most devices, but on the other hand there's no CTS test for it so we probably need to double-check this :)
,
Nov 6 2017
I don't think this is blocking implementing the support library - if it turns out that we cannot use the support library on some devices then so be it, we will simply make sure to fail gracefully.
,
Nov 6 2017
We will however have an eye on this to ensure we aren't unnecessarily failing to use the support library, see crbug.com/781791 |
|||
►
Sign in to add a comment |
|||
Comment 1 by gsennton@chromium.org
, Oct 16 2017