[lazerg]

📜 Description

AndroidConnectionStatusProvider registered the network callback and, since #6146, the telephony listener while holding lock. Both are binder calls. addConnectionStatusObserver and updateCache need the same lock, so SentryAndroid.init on the main thread (through ReplayIntegration.register) waited for registerTelephonyCallback to come back.

Registering and unregistering now use a separate registrationLock. lock still guards the observers and the cache, and it is no longer held across those calls. registrationLock is always taken before lock, never while holding it.

addConnectionStatusObserver also submits the registration to the executor instead of running it on the caller's thread. Otherwise the main thread could still wait on registrationLock while the executor is inside registerNetworkCallback.

💡 Motivation and Context

• resolves: ANR: SentryAndroid.init blocks main thread on AndroidConnectionStatusProvider lock held across registerTelephonyCallback binder call (8.60.0+) #6509
• resolves: JAVA-828

💚 How did you test it?

Added a unit test that adds an observer from a second thread while registerDefaultNetworkCallback and then registerTelephonyCallback are running. It fails on main because the second thread stays blocked on the lock, and passes with this change. :sentry-android-core:testReleaseUnitTest passes.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit dd38ca1. Configure here.}

[cursor]

Background unregister races with async register

Medium Severity

addConnectionStatusObserver now queues ensureNetworkCallbackRegistered on the executor instead of registering on the caller. onBackground still returns immediately when networkCallback is null, without taking registrationLock or enqueueing unregister. networkCallback is only set after both binder registrations finish, and those calls are the slow path this change is removing from init. If the app backgrounds while that work is queued or in progress, unregister is skipped and the network and telephony callbacks stay registered in the background until a later foreground-then-background cycle.

Additional Locations (1)

• sentry-android-core/src/main/java/io/sentry/android/core/internal/util/AndroidConnectionStatusProvider.java#L554-L559

 

^{Triggered by project rule: AGENTS.md}

^{Reviewed by Cursor Bugbot for commit dd38ca1. Configure here.}

[0xadam-brown]

@lazerg - Thanks a bunch for this and for digging into #6509 so quickly. Your diagnosis was spot on, but we've decided to close this in favor of #6537. It builds on the same core fix as yours but goes further for a few related paths that could still block the main thread:

• refreshing the connection cache while holding the lock
• notifying observers and network callbacks while holding a lock
• a registration racing close()

You'll be credited as a co-author when it's merged. Thanks again for the contribution, it's really appreciated! 🙏