Re: [EXTERNAL] Re: ANR in NetworkChangeNotifierAutoDetect - seeking advice

[Ke Yu]

Thanks a lot for the context and suggestions — really appreciate it.

Looping in net...@chromium.org as recommended.

We’d really appreciate any guidance  from folks who have worked on this area recently.

Regards,

Ke

---

From: Paul Jensen <paulj...@chromium.org>
Sent: Wednesday, February 4, 2026 9:11 PM
To: Ke Yu <k...@microsoft.com>
Cc: oks...@chromium.org <oks...@chromium.org>; Haibo Yu <yuh...@microsoft.com>; Yu Jiang <yuj...@microsoft.com>; Wenbin Liu <liuw...@microsoft.com>
Subject: [EXTERNAL] Re: ANR in NetworkChangeNotifierAutoDetect - seeking advice

 

I haven't worked on NetworkChangeNotifierAutoDetect in maybe 5 years, so it's probably best to reach out to net...@chromium.org or other folks who have worked on it more recently.

WRT using NetworkCapabilities passed to onCapabilitiesChanged(), I believe those are only the capabilities for one network, so you'd have to cache and track the capabilities for all networks.

WRT why the current implementation makes synchronous getNetworkInfo() calls, I think this is done to ensure we always get the most up to date information.  Looks like getNetworkInfo() is now deprecated in favor of using things like NetworkCallbacks.

On Wed, Feb 4, 2026 at 4:24 AM Ke Yu <k...@microsoft.com> wrote:

 Hi  Team,

I'm from the Edge Mobile team, we're investigating ANR issues in Edge Android where getNetworkInfo() is called on the main thread within NetworkChangeNotifierAutoDetect, performing synchronous Binder IPC to ConnectivityManager.

 Current code:

This call goes through getNetworkInfo() which performs a Binder IPC on the main thread, leading to potential ANR.

We're considering two possible approaches and would like your input:

1. Use NetworkCapabilities directly (where available): In callbacks like onCapabilitiesChanged(), the NetworkCapabilities parameter already contains transport information. Could we derive the connection type from it instead of calling getNetworkInfo()?

2. Use cached network state: Commit 4fab437979e8 introduced caching for network state. Could more code paths use getCurrentNetworkState() (which returns cached data) instead of making fresh system calls?

Are there specific reasons why the current implementation makes synchronous getNetworkInfo() calls instead of using these alternatives? Are there edge cases we should be aware of?

Any guidance would be greatly appreciated!

Thanks,

Ke

[Matt Menke]

Looks like no one's touched that code, apart from global refactors, since Paul did in 2021.

net/Android files don't change much, and I don't believe the network stack team in general has a whole lot of Java / Android Java API expertise, so I don't think you'll be able to get much guidance from folks on net-dev, unfortunately, unless Adam Rice has something to say, as a reviewer of the CL you linked. The author/reviewers of that CL may be your best bet. I see you CCed the author, and as I said, Adam Rice is on this list. I assume Min Qin was a reviewer because it touched downloads, so may not have useful knowledge. Not familiar with Alexander Timin.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/SI2P153MB0490C71F639890D49E96363CA666A%40SI2P153MB0490.APCP153.PROD.OUTLOOK.COM.

[Adam Rice]

+lorenzo for Android networking.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvqRUeOnoKXChb9YZYVKfH_gM_-_UyeNn9MxrjXjYvXerg%40mail.gmail.com.