Sounds like a reasonable idea; we can probably not worry about the android.webkit dependencies a huge amount right now and skip the APIs that depend on those bits while that gets refactored in parallel?

Er, I mean, fixing the parts where lower levels of the WebView code below glue depend on android.webkit types - the constants are fine, and a lot of the non-constant types seem like things we don't need to have working in a basic prototype.

Yeah, the prototype is not dependent on the change to make lower layers free from android.webkit dependencies. :)

Progression note:
So far I've taken the approach to just prototype certain parts of the support library that I thought would be good to verify, so far this means implementing the minimum stuff needed to render a WebView on screen, and implement a WebViewClient callback.

In light of the recent bug ( crbug.com/752509 ) about calling super-methods with reflection, I think it's better to properly prototype the entire library (to make sure we're not missing some major implementation issue). I.e. create a prototype that can pass CTS tests (and any other tests we run against android.webkit).
We should be able to reuse a lot of the code in the prototype for the real thing.

Progress note: I've now (actually a couple of weeks ago) prototyped version mismatches between the support library and the WebView APK.
I wrote a doc related to this here:
https://docs.google.com/a/google.com/document/d/1tWqpheLadfFhxnVD_eFnRneVwqWfATIml0w1INAm3jk/edit?usp=sharing

We should also prototype using an interface-jar to build the support library glue against (so far I've built the glue against the entire support library implementation). This should be a matter of building interface-jars from the existing support library prototypes and then building the glue against those jars instead of the full-fledged ones.

Re comment #9: using an interface-jar in the sense of what clank is using to build against the Android framework does not make sense here - instead we will split the WebView Support library into one app-facing component, and one WebView-apk facing component (containing only interfaces for the WebView APK glue layer to implement/use).

Note that we are now going with an approach which only provides WebView APIs added since L+, and I don't think it makes much sense to prototype that entire API surface without pushing the prototype to the Android support library directory - we're getting to a point where making the prototype closer to the final product would take a similar amount of work as creating the actual library.