Actually, I believe I just hit one of these issues - if we use the same classloader for the WebView support library as for the normal android.webkit APIs we can run into problems whenever any shared state is altered in either of the glue-layers.

For example: we currently call ContextUtils.initApplicationContext() from WebViewChromiumFactoryProvider (inside the existing WebView glue). If we duplicate that code to live inside the support_library_glue we will try to set the application context twice, and cause a crash. We can fix / work around this specific crash fairly easily, however, fixing this in a generic way so that arbitrary static (shared) state doesn't clash in the future is more tricky. For this issues having a shared layer just below the glue-layers (see  crbug.com/735943 ) should help (and then initiate any shared state from there, and ensure it can't be initiated several times from the different glue-layers).

I think the case in #1 should be ok though? initApplicationContext with the same context is a NOP, and ResourcesContextWrapperFactory will return the same wrapped context, assuming it's passed the same application context.

But in general any state (including stuff that's implicit due to global initialization and cleanup) encoded in the glue layer should be treated with suspicion.

I wonder if such state should be moved outside of both glue layers, so that it's clear that it's shared?

Regarding moving stuff outside of the glue-layer: yeah I think that would be nice, I did file  crbug.com/735943  to take a look at that.

After thinking a bit more about this:
The main classes we are concerned with when it comes to WebView-startup are WebViewChromiumFactoryProvider, and WebViewChromium. Most other classes in the glue-layer are pure adapters.

WebViewChromiumFactoryProvider is created (at most) once per application process, and can later be retrieved from WebViewFactory.getProvider(). WebViewChromiumFactoryProvider is essentially the static interface for WebView - this the class we call into when calling static WebView APIs like WebView.clearClientCertPreferences(), or WebView.initSafeBrowsing(). Evertyhing happening within the WebViewChromiumFactoryProvider initialization code should only happen once per process, so we don't want to duplicate this initialization. We do however want access to some of the object created during this initialization, from the support_library_glue. For example the AwBrowserContext.
So IMO it makes sense to move most of the code in WebViewChromiumFactoryProvider into its own (probably singleton) class that will keep track of all the lower-layer objects that WebViewChromiumFactoryProvider is currently keeping track of. In this way we can access these process-wide lower-level objects from both the old (frameworks-facing), and the new (support library) glue layer. This would also turn WebViewChromiumFactoryProvider into more of a pure adapter class.

WebViewChromium is created once per WebView, i.e. it is the interface through which we implement non-static WebView APIs (e.g. WebView.loadUrl()). It is not entirely clear to me whether we want to put this initialization-code in its own class as well - it seems to be heavily dependent on the targetSdkLevel of the app using WebView, and we might want this to work differently in the support library.

Hmm, it would probably have made more sense to post comment #3 to  crbug.com/735943  ;). Ah well.

We probably want a WebView-shell test to ensure we are supporting this use case. I.e. the test would create a normal WebView, and a support library WebView, and then ensure they both can be started and load some URL.

This is covered by the design of the support library glue - we share code between the support library glue and the webkit glue so that they don't interfere with each other.

We should add either a webview shell test or a support library test to ensure at least some APIs do work together as expected - i.e. that getters and setters on WebSettings affect the getters and setters of the corresponding WebSettingsCompat.

I think we could implement this test nicely with {get,set}WebViewClient. That should be done when we add the API for WebViewCompat#getWebViewClient ( issue 852920  and http://b/110225598)

Since this is tracked implicitly by those issues, I'm going to close this.