We've been trying to keep the generated scripts non-Chrome-specific, in that they work for *any* apks that we build.

We could always just add a "webview_mode=true" for some targets though. I'm not sure we'd need to though.


For argv not working on system_webview_shell_apk:
 * Need to set "command_line_flags_file" on the android_apk().

For making it the webview provider:
 * Is there anything in the apk that identifies it as a webview provider? E.g. we could enable setting it as the provider if we can "sniff" that it's capable. 
 * Alternatively, we could just whitelist the list of package IDs that are webviews and set them as providers based on package id.

bin/system_webview_google_apk launch:
 * I think it makes sense this wouldn't work. We could make this a "webview mode" thing though if you feel strongly.


bin/system_webview_shell_apk {logcat,ps,mem-usage} not showing webview renderers:
 * We should just update all apks to apply these commands to associated webview renderers.
 * Are there any ways via adb to figure out if a process is a webview renderer, and what the "owning" process is?

bin/system_webview_google_apk {logcat,ps,mem-usage} not showing browser process:
 * I think this makes sense (for the same reason as launch).

Thanks for taking a look!

---

In terms of technical questions...

> Is there anything in the apk that identifies it as a webview provider?

Not really. The logic for where something is a "valid" webview provider is quite complex, and the result (valid or not valid) is only exposed on O+. Technical details are at http://go/clank-webview/webview-providers).

> Alternatively, we could just whitelist the list of package IDs that are webviews and set them as providers based on package id.

Like I said, this isn't *strictly* correct, but I think it's good enough for the sake of dev productivity. We develop on userdebug nexus/google devices, so we could just assume this list [1] is correct.

> Are there any ways via adb to figure out if a process is a webview renderer, and what the "owning" process is?

I'll defer to Torne :)

---

In terms of policy...

I think there's a tradeoff. We can modify the scripts to improve WebView dev productivity and provide a consistent experience for clankers and chromies to work with WebView, but this comes at the cost of carving out special cases.

In the past, some of my projects have been affected when non-WebView team members have difficulty working with WebView. Not all the friction is technical (use_signing_keys requires ACL approval), but I thought these scripts might be an opportunity to converge workflows and abstract-away some details (e.g., changing webview provider, WebView flags file).

That said, nobody on WebView currently uses these scripts, and don't know if they would do so even if they worked. If you think there's a path forward for providing a clank-like dev experience for WebView (and agree with the value), I'll poll the team for interest. If our team doesn't want to use this, then WontFix might be the best solution.

[1] https://cs.corp.google.com/android/vendor/google/google_overlay/static_only/frameworks/base/core/res/res/xml/config_webview_packages.xml