Bo, I'm not familiar with this code.

Is there some document describing why we need this, and what the callDrawGlFunction is for? (it would be nice to get an understanding of how important the different methods are - i.e. if we want to support as many features as possible from N on an M device, will the older drawGlFunction methods in that framework limit our possibilities somehow?) 


What did we do on L when we didn't have the WebViewDelegate, did we call these methods/functionality directly?

These are just APIs on android that's used by webview, but we don't want regular apps to use. So they are not in the regular sdk.

> Is there some document describing why we need this, and what the callDrawGlFunction is for?

Nope. We just changed things as we needed..

> if we want to support as many features as possible from N on an M device, will the older drawGlFunction methods in that framework limit our possibilities somehow?

In theory, yes. But looking through current stuff in WebViewDelegate, not really..? I suppose isMultiProcessEnabled counts as one, if it weren't for all the other stuff that's also required as well.

> What did we do on L when we didn't have the WebViewDelegate, did we call these methods/functionality directly?

reflection: https://cs.chromium.org/chromium/src/android_webview/glue/java/src/com/android/webview/chromium/WebViewDelegateFactory.java?rcl=fe199f4407a2d90e1cd7d95b072896f17cfd0f97&l=223

We added WebViewDelegate in L mr1. Hopefully there aren't that many devices with L..

Well, the isMultiProcessEnabled interface doesn't make any sense on L/M anyway..?


Haha, right, so the WebViewDelegate is essentially turning all of the hidden APIs we need to reach from WebView into SystemApis, seems legit ;)


Anyway, so on L MR1, and above, we should be able to call WebViewDelegate directly from the support library (since it's a system API), but on L we would probably want a dupe of the existing WebViewDelegateFactory.Api21CompatibilityDelegate but in our support_library_glue instead of the normal glue..? (or potentially in the support library code itself).

Given that WebViewDelegate is only used within WebView APK code we will want to create the WebViewDelegate for L MR1 and above from the support_lib_glue layer (as opposed creating the WebViewDelegate in the support library code and passing it to the support_lib_glue). The only reason to put the WebViewDelegate creation/calling into the Support Library itself would be if we could somehow make the Support Library not support all potential future Android versions (so that we can deprecate some WebViewDelegate API without breaking existing support library versions / WebView versions), since that would then be better than putting the code in the support_lib_glue which has to support all upcoming Android versions. I doubt we will be able to make the support library avoid supporting all upcoming Android versions :)

We should also move the WebViewDelegateFactory.Api21CompatibilityDelegate to a lower layer to be shared between the two glue layers. And possibly move the entire rest of the WebViewDelegateFactory class as well, to share it between the glue layers.

It seems to make sense to use the WebViewDelegate together with API-level checks from within the support-library-glue to avoid creating our own (possibly buggy) version of the WebViewDelegate. On the other hand, up until now I've argued for removing references to android.webkit* from the WebView APK (including the support-lib-glue layer) to avoid any unnecessary dependencies on framework code. Am I missing something here that would make us want to have the support-librar-glue not depend on the android.webkit.WebViewDelegate?

It's fine. I guess android.webkit.WebViewDelegate isn't really part of public android.webkit.*. Also we were only talking about removing android.webkit dependency from rest of chromium code, not from glue.

While we're on the topic of using classes from android.webkit - it seems like there are more classes created for similar reasons as WebViewDelegate.
Especially JsDialogHelper, and FindActionModeCallback - these two classes would have been possible to implement in the WebView APK if they wouldn't be using com.android.internal.R - and both those classes are System APIs (not public APIs).

I'm tempted to use these classes from the support library glue layer as well.

Given that we'll use an augmenting approach for the support library - AFAICT we don't have any problems with SystemApis.