I suspect the problem is related to using RandomBind() for UDP sockets, since that's what the async resolver does that's unique and seems like a likely place to get this sort of error. I did some more digging in histograms, and I found that this is mostly a problem on newer Android, at least in the dev channel population. It goes from basically nonexistent in J to 1% of all DnsTask resolutions in N and O. And it's a small number of unique users pre-N, over half of them on N, and nearly all of them on O. All of this could be population bias and I should look at it again on stable if I haven't fixed this by then.

The frequency of the problem on N and O is kinda suspiciously close to 1%, as if exactly 1% of our port range is bad for some reason. But I haven't been able to reproduce locally so far and it might not actually be that simple.

This still isn't actually a high-priority problem, it'll fail immediately and fall back to ProcTask.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

rch@ mentioned similar EACCESS errors in QUIC code when sending UDP packets.  lorenzo@ mentioned some possible causes:

The device has various modes where networking is restricted, such as doze, battery saver, app standby. It also has metered network restrictions such as data saver, data usage limits, always-on VPNs that limit network traffic, and network permissions on networks that are in the background.

Most of these exempt the foreground application, but not all of them. They are mostly implemented using iptables rules, and depending on the rules it's quite likely that some of them return EACCES or EPERM to UDP send attempts.