Note: we might end up rolling the support library API into clank instead of the other way around.

I wonder whether there might be any issues related to both the WebView Support Library, and the WebView APK, having to roll their own version of the Android frameworks jars..

To clarify the setup

Android SDK - lives in Android master
WebView Support Library - lives in Android support library tree/branch.
WebView Support library Glue - lives in Chromium tree, with the rest of the WebView APK code

The Android support library master branch is built against an Android frameworks jar that is updated regularly from the Android master branch.
We (WebView team) will drop WebView Support Library jars into the Chromium tree for the glue to build against.

I think the main issue here will be hiding APIs that target the next Android release - we will probably have to add a next/ layer for the WebView Support Library glue to hook up with unpublished APIs.

I talked a bit to lizeb@ about how Custom Tabs are doing this - and it seems we are a bit restricted here:
A. the Android Support Library repo is not public, so we can't just pull code from that into (public) chromium.
B. Custom Tabs are developing and testing their code in their chromium repository - so they can't first land code in the Android support library and then later pull that into chromium, they have to first test the code in chromium to make sure it works/sticks. So they're hosting their support library code in a GitHub repository as well, and they are manually updating the github repo to the Android Support Library repo to match each other. Chromium then seems to pull the code from the github repo.


It would be great if we could come up with a less contrived solution.
Maybe we could
1. produce a (public) jar from the support library code targeting already-released Android versions, and build the upstream chromium glue layer against that, and
2. have the downstream (Clank) glue layer depend on the actual Android Support Library repo (since Clank is private).

I talked to Aurimas yesterday - and there are some restrictions in how we would publish a jar from the support library (for example, publishing such a jar from there would also indirectly publish any new package naming used by the support library). In general it's just tricky to publish a jar from a closed-source repo to an open source repo (since you have to be careful about what you add in that jar).

Aurimas suggested putting the interfaces in the Chromium repo instead - and then pull them into the support library. I don't see any problem with this, but would like to scope out exactly what this means for WebView developers whenever we want to add a new Android API, before implementing this approach.

Note that, for prereleased Android APIs we will have to keep the interfaces in clank/ to not release them too early, so the support-library-master branch will pull interfaces from clank (and upstream chromium), while support library branches targeting already-released android versions (e.g. support-library-o-mr1) will pull from upstream chromium, since we can put released APIs there.

We talked about this during the sync meeting yesterday, and it seems the most decent solution right now is to just create the interfaces that connect the support library and the glue, in upstream chromium.
We will use gsubtreed to mirror a subrepo of chromium (somewhere under android_webview/), containing only the interfaces we want to share between the support library and the glue layer.

Ideally we would have a script taking an Android frameworks jar, and producing the support library interfaces, given a pre-created list of APIs to avoid (i.e. APIs added before L).
Then we could start creating those interfaces from a public Android jar built from O, and later build the interfaces from some jar built from P.

Next steps:
1. create a directory under android_webview/ to host the shared interfaces
2. file a chrome-infra bug to mirror that directory publicly
3. mirror the new public directory into the Android Support Library to be able to build against the shared interfaces

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b1ea1aff463b4c061a3c7f60894129bff89e8bb1

commit b1ea1aff463b4c061a3c7f60894129bff89e8bb1
Author: Gustav Sennton <gsennton@google.com>
Date: Wed Nov 15 14:05:13 2017

[WebView] Add directory for interfaces between support library and glue

We will build a set of interfaces to communicate between the WebView
support library (statically built into apps), and the WebView support
library glue layer (built into the WebView APK, loaded into app
processes at run-time).

To allow Chromium and the Android Support Library to share these
interfaces we put them in their own directory, and mirror that directory
publicly so that they can be referenced by the support library.

This CL creates the interface directory, and adds some examples of
interfaces.

BUG= 755506 

Change-Id: I3f7040c4ab88c7e0d26379aebc4b74fb53eee1de
Reviewed-on: https://chromium-review.googlesource.com/768712
Commit-Queue: Gustav Sennton <gsennton@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516688}
[add] https://crrev.com/b1ea1aff463b4c061a3c7f60894129bff89e8bb1/android_webview/support_library/boundary_interfaces/BUILD.gn
[add] https://crrev.com/b1ea1aff463b4c061a3c7f60894129bff89e8bb1/android_webview/support_library/boundary_interfaces/DEPS
[add] https://crrev.com/b1ea1aff463b4c061a3c7f60894129bff89e8bb1/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/VisualStateCallbackInterface.java
[add] https://crrev.com/b1ea1aff463b4c061a3c7f60894129bff89e8bb1/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/WebSettingsInterface.java
[add] https://crrev.com/b1ea1aff463b4c061a3c7f60894129bff89e8bb1/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/WebViewProvider.java
[add] https://crrev.com/b1ea1aff463b4c061a3c7f60894129bff89e8bb1/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/WebViewProviderFactory.java

ALright, we now need to pull the mirror created in crbug.com/785265 into the Android Support Library, to build the WebView Support Library against that.

This has been solved for a while, the way we do this is:
1. own a directory in upstream chromium
https://cs.chromium.org/chromium/src/android_webview/support_library/boundary_interfaces/
2. mirror just that directory (not the rest of chromium) to a public git repo:
https://chromium.googlesource.com/chromium/src/android_webview/support_library/boundary_interfaces
3. mirror that public repo into Android (platform/external/webview_support_interfaces, branch: upstream-master):
https://googleplex-android.googlesource.com/platform/external/webview_support_interfaces/+refs
4. manually keep platform/external/webview_support_interfaces master up-to-date with platform/external/webview_support_interfaces upstream-master.

To easier keep track of the history / steps we set this up, relevant bugs:
crbug.com/785265
b/69806605
b/72141309
b/72374805