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.

[Lorenzo Colitti]

Adam, thanks for looping me in.

Ke,

I think your proposal #1 is the way to go. We discourage calling synchronous ConnectivityManager APIs from broadcasts or callbacks not just because they're synchronous and blocking, but because mixing synchronous methods and async notifications leads to ordering issues and race conditions.

The network transport is always present in onCapabilitiesChanged. As Paul points out, the capabilities are for the Network object that is passed by the callback. But if you registered the callback using registerDefaultNetworkCallback, then it will always tell you the capabilities of the default network.

On most Android releases (certainly starting from SDK level 31, possibly starting from 28) it should be possible to get a complete picture of network state using NetworkCallbacks and no synchronous calls, because when the app registers a NetworkCallback, the system will immediately call the callbacks with any currently-matching network (in the case of registerDefaultNetworkCallback, the default network) and their LinkProperties and NetworkCapabilities.

Minimally, I think you just need to listen to onCapabilitiesChanged (which tells you that the default network has either changed or changed its capabilities) and onLost (which tells you that there is no longer a default network), and just cache the latest NetworkCapabilities received. You can then examine the capabilities that to find out what the current default network is without needing to do any IPCs.

Cheers,

Lorenzo