Chrome Crashes When Accessing the Local Network After Upgrading Xiaomi 17 Pro to HyperOS 4.0

A short note about Chrome crashing when accessing local network addresses after upgrading a Xiaomi 17 Pro to HyperOS 4.0, including the ADB fix and the ACCESS_LOCAL_NETWORK AppOps cause.

Symptoms

After upgrading my Xiaomi 17 Pro to HyperOS 4.0 / Android 17, Chrome started crashing whenever it opened local network addresses:

  • Opening the router admin page at http://192.168.10.1/ made Chrome exit immediately.
  • Other local IP addresses and local domains caused the same crash.
  • MT Manager timed out when connecting to NAS SMB.
  • Public internet access on the same phone still worked.
  • Other devices on the same LAN could access the router and NAS normally.
  • Xiaomi Browser could open the same local addresses without any issue.

Device and system version at the time:

1
2
3
4
Device: Xiaomi 17 Pro
Model: 25098PN5AC
System: HyperOS 4.0 / Android 17
Build: OS4.0.0.27.XBLCNXM

At first glance this looks like a network issue, but the key difference is that Xiaomi Browser worked while Chrome and MT Manager did not. That points more toward an app permission problem than a broken LAN.

Fix

Use ADB to check the local network AppOps state for Chrome, MT Manager, and Xiaomi Browser:

1
2
3
adb shell 'cmd appops get --user 0 com.android.chrome ACCESS_LOCAL_NETWORK'
adb shell 'cmd appops get --user 0 bin.mt.plus ACCESS_LOCAL_NETWORK'
adb shell 'cmd appops get --user 0 com.android.browser ACCESS_LOCAL_NETWORK'

The abnormal state looked like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Chrome:
Uid mode: ACCESS_LOCAL_NETWORK: ignore
ACCESS_LOCAL_NETWORK: allow; rejectTime=...

MT Manager:
Uid mode: ACCESS_LOCAL_NETWORK: ignore
ACCESS_LOCAL_NETWORK: allow; rejectTime=...

Xiaomi Browser:
ACCESS_LOCAL_NETWORK: allow; time=...

Chrome and MT Manager had package-level allow, but their UID-level AppOps state was still ignore. In this state, the system settings UI may appear to show the permission as allowed, while the app is still blocked from accessing the local network.

Set the affected apps’ UID-level local network AppOps back to allow:

1
2
adb shell cmd appops set --uid com.android.chrome ACCESS_LOCAL_NETWORK allow
adb shell cmd appops set --uid bin.mt.plus ACCESS_LOCAL_NETWORK allow

If you use wireless debugging, pair the phone first:

1
2
adb pair <phone-ip>:<pair-port>
adb devices -l

After the fix, Chrome could open http://192.168.10.1/ normally again, and MT Manager could access NAS SMB as expected.

Cause

Starting with Android 17, local network protection is enforced for apps targeting SDK 37 or higher. Access to LAN addresses, mDNS, SSDP, NsdManager, and other local network capabilities is affected by ACCESS_LOCAL_NETWORK.

The core issue here was not that Chrome had no permission at all. The permission state was split:

  • Package-level AppOps: ACCESS_LOCAL_NETWORK = allow
  • UID-level AppOps: ACCESS_LOCAL_NETWORK = ignore

After the system upgrade, some apps’ UID-level AppOps state did not migrate correctly. This created a situation where the settings UI could look correct, but actual local network access was still blocked.

Xiaomi Browser did not have the UID-level ignore state, so it could access the same local addresses normally. Chrome and MT Manager were blocked by UID-level AppOps, showing up as a crash in Chrome and an SMB timeout in MT Manager.

The Chrome crash was not a normal DNS failure or TCP timeout. The crash log showed Chrome failing in its own NetworkService thread and libchrome.so:

1
2
3
4
Fatal signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)
name: NetworkService  >>> com.android.chrome <<<
backtrace:
  /data/app/.../com.android.chrome.../base.apk!libchrome.so

In short, the abnormal system permission state triggered a Chrome network service crash.

Notes

  • Only run ACCESS_LOCAL_NETWORK allow for apps that actually need local network access.
  • If another app has the same problem, replace the package name and repeat the check and fix.
  • You can find package names with adb shell pm list packages | grep -i <keyword>.
  • Future system or app updates may change AppOps state again. If the issue comes back, recheck the UID-level permission.

References: