Summary
Some users hit an intermittent java.net.UnknownHostException: Unable to resolve host "...": No address associated with hostname on network calls — most visibly during sign-in (device-code fetch) and the About Check for updates. It is intermittent and not tied to a specific network (reproduced on both Wi-Fi and mobile data, with the host reachable from the same device's OS resolver at the same time).
Root cause (as far as diagnosed)
The app's own network stack is healthy — the Home feed loads fine via the shared OkHttp client (Conscrypt + custom DNS), and the same youtube.com host pings successfully from the device shell while the app reports it unresolvable. The failure is the OS resolver intermittently returning no address to the app process for a short window.
Notes:
- IPv4-first DNS is already the app default (
GlobalPreferences → DNS_TYPE_IPV4); it only reorders system-resolved addresses, so it cannot help when the system returns nothing.
- Device had Private DNS =
opportunistic.
Mitigations already shipped (31.77-mobile-alpha4)
These reduce the symptom but do not fully eliminate it:
- Check for updates now routes through the app's shared
OkHttpManager client instead of a raw HttpURLConnection (the raw path was a separate, weaker stack that failed independently).
- Sign-in auto-retries a transient device-code failure up to 3× (2s backoff) before showing "Sign-in failed"; the manual Retry button remains.
These absorb momentary blips. A sustained resolver outage during the retry window will still fail.
Possible next step (not yet done)
Add a public-DNS fallback on system-miss (e.g. 8.8.8.8 via the already-bundled dnsjava, see PublicDnsResolver) so the app can resolve when the OS resolver returns nothing. Tradeoff: fails on networks/carriers that block outbound port 53 to public resolvers, so it must be a fallback, not the default.
Asks for reproduction
A logcat capture at the moment of failure (full stack trace of the UnknownHostException) would confirm whether it's the device-code call specifically and whether retries are firing, and justify taking on the public-DNS-fallback tradeoff.
Summary
Some users hit an intermittent
java.net.UnknownHostException: Unable to resolve host "...": No address associated with hostnameon network calls — most visibly during sign-in (device-code fetch) and the About Check for updates. It is intermittent and not tied to a specific network (reproduced on both Wi-Fi and mobile data, with the host reachable from the same device's OS resolver at the same time).Root cause (as far as diagnosed)
The app's own network stack is healthy — the Home feed loads fine via the shared OkHttp client (Conscrypt + custom DNS), and the same
youtube.comhost pings successfully from the device shell while the app reports it unresolvable. The failure is the OS resolver intermittently returning no address to the app process for a short window.Notes:
GlobalPreferences→DNS_TYPE_IPV4); it only reorders system-resolved addresses, so it cannot help when the system returns nothing.opportunistic.Mitigations already shipped (31.77-mobile-alpha4)
These reduce the symptom but do not fully eliminate it:
OkHttpManagerclient instead of a rawHttpURLConnection(the raw path was a separate, weaker stack that failed independently).These absorb momentary blips. A sustained resolver outage during the retry window will still fail.
Possible next step (not yet done)
Add a public-DNS fallback on system-miss (e.g. 8.8.8.8 via the already-bundled
dnsjava, seePublicDnsResolver) so the app can resolve when the OS resolver returns nothing. Tradeoff: fails on networks/carriers that block outbound port 53 to public resolvers, so it must be a fallback, not the default.Asks for reproduction
A logcat capture at the moment of failure (full stack trace of the
UnknownHostException) would confirm whether it's the device-code call specifically and whether retries are firing, and justify taking on the public-DNS-fallback tradeoff.