It looks like supporting KitKat should be very similar to supporting old WebView versions (ones without the new support library glue), which we need to do anyway (otherwise uninstalling WebView on e.g. a device running Oreo would make the WebView Support Library stop working):


We need conversion classes between each android.webkit class (e.g. WebViewClient) and its corresponding class in the support library - i.e. we essentially need a whole new layer doing this (yuck!).

Looking at a single call into WebView it would look something like this:

We keep the WebView->WebViewProvider interaction:

support_library.WebViewProvider has two possible implementations:
WebViewProviderOld (supporting KitKat and old WebView versions), and
WebViewProviderModern (calling into WebView APKs containing the new support-library-glue-layer).

Note that WebViewProviderOld can't just delegate to the android.webkit.WebViewProvider directly because it needs to convert support-library classes to android.webkit classes, e.g. in the case of setWebViewClient the call chain is the following:
support_library.WebView.setWebViewClient(support_library.WebViewClient) ->
    support_library.WebViewProviderOld.setWebViewClient(support_library.WebViewClient) ->
        android.webkit.WebViewProvider.setWebViewClient(createWebkitWebViewClient(support_library.WebViewClient));

Depending on the state of the device we would either create a WebViewProviderOld or a WebViewProviderModern instance, and store that in the support_library.WebView as its support_library.WebViewProvider.

Any API/SDK version handling would be handled in WebViewProviderOld and WebViewProviderModern rather than by the WebView class itself.



I have not prototyped this design - I probably should :)

Hmmm, when we create a WebViewChromium through WebViewFactoryProvider.createWebView(..) for use in WebViewProviderOld we need an android.webkit.WebView, and a WebView.PrivateAccess object.
This is a bit ugly... ideally we would pass our support_library.WebView object through createWebView(..), but that would mean that our support_library.WebView object needs to subclass the android.webkit.WebView.

An alternative might be to create a new class 
SupportWebViewRelay overrides android.webkit.WebView
that would own our support_library.WebView object and delegate any calls to the support_library.WebView object.. but then creating that SupportWebViewRelay would result in creating a WebView object, i.e. calling the constructor for WebView, and thus loading another WebViewProvider from the WebView APK code - a WebViewProvider which would be completely unused. That seems unnecessary..


I think we can't really create/use an android.webkit.WebViewProvider object directly on KitKat (or for non-up-to-date WebViews) without creating two WebViewProvider objects - one for us to use, and one for the android.webkit.WebView we need to pass to the WebViewProvider. So I think what we need to do instead is to create an entire android.webkit.WebView object and just delegate all our (support_library.WebView) calls to that. I'm not sure if that makes sense from a View Hierarchy perspective.

Torne/Bo/Toby wdyt? Maybe I'm missing something obvious..

Given our new approach to only provide L+ APIs we won't need to provide support for KitKat/JellyBean - developers will have that support through the android.webkit API.

As for non-up-to-date WebViews IMO it doesn't make sense to provide support for those for two reasons:
1. WebView has a high update-rate
2. old WebViews won't be built against support library interfaces, so any objects used/passed are limited by the Android version on the device.



Marking this as WontFix as we don't explicitly need to provide support for KitKat (we do that through the android.webkit API anyway).
We should make sure the support library doesn't break on old versions of WebView (i.e. it doesn't crash).