Repository navigation
ANR: SentryAndroid.init blocks main thread on AndroidConnectionStatusProvider lock held across registerTelephonyCallback binder call (8.60.0+) #6509
Description
Integration
sentry-android
Build System
Bazel
AGP Version
N/A
Proguard
Enabled
Other Error Monitoring Solution
No
Version
8.60.0
Steps to Reproduce
Version
8.60.0 (pattern still present in 8.63.0)
Steps to Reproduce
Not reproducible on demand; it depends on ITelephonyRegistry binder latency (the com.android.phone process). Observed in production right after upgrading from 8.52.0 to 8.60.0:
- Call
SentryAndroid.initfromApplication.onCreatewithsentry-android-replayon the classpath (replay sample rates don't matter, see below). AndroidConnectionStatusProvider's constructor submitsensureNetworkCallbackRegistered()to the Sentry executor (AndroidConnectionStatusProvider.java:108).- On the executor thread,
ensureNetworkCallbackRegistered()acquireslock(line 203) and, while still holding it, callscellularNetworkTechnologyProvider.register()(line 370), which callsTelephonyManager.registerTelephonyCallback(...), a synchronous binder IPC. - Meanwhile, on the main thread,
Sentry.init→ReplayIntegration.register(line 152) →addConnectionStatusObserver(line 457) tries to acquire the samelockand parks until the binder call returns.
ReplayIntegration is installed whenever sentry-android-replay is on the classpath (AndroidOptionsInitializer, isReplayAvailable), and register() has no sample-rate check. So setting sessionReplay.sessionSampleRate / onErrorSampleRate to 0 does not avoid the wait.
The telephony registration under the lock came in with #6146 ("Add cellular network technology to connection type"), first released in 8.60.0. We saw zero events with this signature on 8.52.0.
Expected Result
SentryAndroid.init on the main thread never waits on a binder call made by a background Sentry thread. For example, registerTelephonyCallback (and ideally registerNetworkCallback) runs outside lock, or addConnectionStatusObserver doesn't need the same lock as callback registration.
Actual Result
Foreground ANRs (ApplicationExitInfo REASON_ANR) during Application.onCreate, mostly on Pixel devices (Pixel 9a, Pixel 10 Pro XL; Android 16/17), plus some low-end devices. Thread dump excerpt:
"main" Waiting
at jdk.internal.misc.Unsafe.park
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:226)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:790)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:323)
at io.sentry.util.AutoClosableReentrantLock.acquire(AutoClosableReentrantLock.java:37)
at io.sentry.android.core.internal.util.AndroidConnectionStatusProvider.addConnectionStatusObserver(AndroidConnectionStatusProvider.java:457)
at io.sentry.android.replay.ReplayIntegration.register(ReplayIntegration.kt:152)
at io.sentry.Sentry.init(Sentry.java:390)
at io.sentry.Sentry.init(Sentry.java:251)
at io.sentry.android.core.SentryAndroid.init(SentryAndroid.java:103)
at io.sentry.android.core.SentryAndroid.init(SentryAndroid.java:84)
... (Application.onCreate)
"SentryExecutorServiceThreadFactory-0" Native <-- holds lock
at android.os.BinderProxy.transactNative
at android.os.BinderProxy.transact(BinderProxy.java:674)
at com.android.internal.telephony.ITelephonyRegistry$Stub$Proxy.listenWithEventList(ITelephonyRegistry.java:1452)
at android.telephony.TelephonyRegistryManager.listenFromCallback(TelephonyRegistryManager.java:322)
at android.telephony.TelephonyRegistryManager.registerTelephonyCallback(TelephonyRegistryManager.java:1655)
at android.telephony.TelephonyManager.registerTelephonyCallback(TelephonyManager.java:17555)
at android.telephony.TelephonyManager.registerTelephonyCallback(TelephonyManager.java:17450)
at io.sentry.android.core.internal.util.CellularNetworkTechnologyProvider.register(CellularNetworkTechnologyProvider.java:100)
at io.sentry.android.core.internal.util.AndroidConnectionStatusProvider.ensureNetworkCallbackRegistered(AndroidConnectionStatusProvider.java:370)
at io.sentry.android.core.internal.util.AndroidConnectionStatusProvider.lambda$new$0(AndroidConnectionStatusProvider.java:108)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:520)
"ConnectivityThread" Waiting <-- also parked on the same lock
at io.sentry.util.AutoClosableReentrantLock.acquire(AutoClosableReentrantLock.java:37)
at io.sentry.android.core.internal.util.AndroidConnectionStatusProvider.updateCache(AndroidConnectionStatusProvider.java:380)
at io.sentry.android.core.internal.util.AndroidConnectionStatusProvider$1.updateCacheAndNotifyObservers(AndroidConnectionStatusProvider.java:295)
at io.sentry.android.core.internal.util.AndroidConnectionStatusProvider$1.onCapabilitiesChanged(AndroidConnectionStatusProvider.java:279)
at android.net.ConnectivityManager$NetworkCallback.onAvailable(ConnectivityManager.java:4138)
The only workaround we see is pinning to 8.59.0, which predates #6146. We'd prefer to move forward once the telephony registration no longer happens under lock.
Activity
linear-code commentedon Nov 6, 2026
JAVA-828
romtsn commentedon Nov 6, 2026
@Vandalko thanks for the detailed report, it looks legit! We'll take a look in the next couple of weeks 👍
fix(android): Don't block callers on connection status registration
ref(android): Hold the connection cache in an immutable snapshot
docs(android): Correct what reading a lost connection snapshot does
fix(android): Don't register connection callbacks again after close
fix(android): Don't block callers on connection status registration
ref(android): Hold the connection cache in an immutable snapshot
docs(android): Correct what reading a lost connection snapshot does
fix(android): Don't register connection callbacks again after close
fix(android): ADDRESS PR COMMENT: Keep a cache refresh's result when …
ref(android): Add ConnectionSnapshot.toString for debugging
0xadam-brown commentedon Nov 10, 2026
@Vandalko – we've merged a fix for this and plan to include it in our next release (8.64.0)
github-actions commentedon Nov 11, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #6537, which was included in the 8.64.0 release.