As you probably know, we need to be careful with this as it may have significant performance implications.  Many networks are IPv6-only with NAT464, so IPv4 is slower and less reliable.

Blackholing IPv6 while the screen is locked was likely a power-saving WiFi feature or a byproduct of one, because the phone didn't have to get woken up all the time by ICMP6 RAs on WiFi.  One of the goals of adding APF support to Android Nougat was that I could standardize the WiFi power-saving packet filtering in a safe and efficient manner.

If we are going to consider enabling this we may want to consider adding lots of restrictions about when it's enabled:
1. only on Android Lollipop and earlier, and
2. only on specific Android devices, and
3. only for connections established on WiFi, or QUIC IPv6 connections migrated to WiFi

Agreed with all those constraints.

(Android devices running Android 6.0.1 or later should have passed the ConnectivityScreenOffTestActivity CTS test, which checks for this misbehaviour.)

I looked at this. Given how the code is currently structured, the "sad eyeballs" suggestion would be a mess to implement when using the system resolver, but disallowing ipv6 entirely under the conditions Paul listed is very feasible. I can plumb it through as a Cronet-only feature if people don't want it in Chrome, but my preference is for adding it in Chrome and keeping an eye on metrics.

Before we do anything, can we find out how whether this is a problem for Chrome? Adding a workaround is easy, but removing it can be hard. Can we make sure the code complexity is justified?

I don't expect this to be a net change in code complexity, since this is just adding a few simple checks in one place and it'll allow us to revert https://codereview.chromium.org/2709393007/. And we're pretty sure we need a better solution in Cronet than what we have right now, so the code is going to get added anyway, the question is whether we want it enabled in Chrome or not.

I don't know a way of telling from metrics whether this is causing a problem right now. We'll be able to watch for changes once it's implemented, though.

We may want to measure the impact of this problem before taking action that might have adverse side-effects.  I don't imagine Chrome performing many network requests while the screen is locked.  net::UrlRequest::OnSuspend() cancels requests when the device suspends and net::HttpNetworkLayer::OnSuspend() closes idle connections on Windows; these actions should decrease the number of network requests active when the screen is locked.

OnSuspend() doesn't exist on Android: https://cs.chromium.org/chromium/src/base/power_monitor/power_monitor_device_source_android.cc?l=28

The use case mentioned in  issue 644515  seems like one that might be affected by the IPv6 issue, but I can't think of a good way to measure impact without running an experiment. So I'll have to implement the workaround in a way that can be turned on only for Cronet anyway, because it's definitely needed there, and then it'll be there to run an experiment in Chrome with if we want to in the future.