AW should probably not depend directly on NetworkService::net_log, and instead use the corresponding Mojo interfaces, like Chrome does.

If netlog people have advice for how to test this in AW, that would be appreciated. This is a tool we use so infrequently, we'll surely never notice if our plumbing breaks.

Alternatively, we could just let this regress until we have a need to integrate netlog (to my knowledge, the team has only used netlog in WebView once).

If you aren't using it, it should be fine to let it break, as long as it's fine that the network stack team can't help much in investigating any WebView-specific network issues that crop up, until after it's hooked up.  Things will certainly work completely fine without anyways to grab a NetLog capture.

If it isn't being actively used, dropping support and adding it back later is a fine option.

Supporting it shouldn't be too hard though:

From what I can tell, AW is just implementing support for --log-net-log command line flag.

In the network service world, support for that commandline flag is already done by network_service_instance.cc (--log-net-log command line is forwarded to the utility process).

You would need to do at least the following:
  (1) Modify the predicate here https://cs.chromium.org/chromium/src/android_webview/browser/net/aw_url_request_context_getter.cc?q=android_webview/browser/net/aw_url_request_context_getter.cc&sq=package:chromium&g=0&l=226 so that it also excludes when base::FeatureList::IsEnabled(network::features::kNetworkService). Otherwise you will get double-logging to the same file and corruption ensues (we already have experience with that bug :)

  (2) Sort out the differences in paths. Right now AW interprets the --log-net-log as a filename relative to base::DIR_ANDROID_APP_DATA, whereas the networkservice version does not. If you do nothing one would now need to specify an absolute path to have the file end up in the same destination, which is probably fine.