Hm, this raises the question of which classes we should just add new APIs for and which ones we should add the entire class either way. E.g. classes passed in WebViewClient callbacks, like WebResourceError, should probably contain all APIs rather than just new ones - since you can't use the old android.webkit class to make calls for old APIs (unless we include getOldWebkitClass() method instead of the old APIs, but that seems ugly/unnecessary).

Not sure how to determine automatically which classes require us filling in all their methods, a guess would be this should only hold for classes passed to app-callbacks. But will have to investigate more.

thinking a bit more about this I think we essentially can choose ourselves which classes should hold a getter returning the corresponding android.webkit object (like WebViewCompat having getWebView() return an android.webkit.WebView), and which classes should contain the entire android.webkit API (this should make more sense for smaller classes like WebResourceError).

It might even make sense to have a cut-off limit - something like, if a class contains less than say 10 methods, then we will implement it fully in the support library, but if it has more than that many methods we will add a getter for its corresponding android.webkit class.

Another question here is whether we want to add methods from superclasses, like methods added since L in View for WebView. I'll have to check which ones have been added recently - fetching new methods from the superclasses of e.g. WebView will make the code for fetching new APIs slightly more contrived since we'll have to go outside of android.webkit (but still within frameworks/base/).

Toby/Torne do you know any new (since L) superclass methods we should implement for WebView, i.e. new methods on AbsoluteLayout / View?

It kind of makes sense to only add methods that are defined explicitly on WebView, i.e. not methods where the definition lives in a super class, since methods defined on the super class shouldn't call into the WebView APK anyway.

Closing this for now since we're no longer pursuing code generation for the support library.