perf(connectivity): Cache network capabilities and status to reduce IPC calls

[romtsn]

📜 Description

• Register network callback on a bg thread upon AndroidConnectionStatusProvider instantiation
• Cache latest available NetworkCapabilities for 2 minutes
• Use the capabilities to determine the current network status and type
  • If it's not available (cache expired), we'd fallback to retrieving it proactively and caching it
  • pre-API-23 we'd be always querying it, but it's a very small number of devices
• onLost/onUnavailable would immediately send DISCONNECTED now as opposed to retrieving connectionStatus again
• Implement a isSignificantChange check, because onNetworkCapabilitiesChanged can be called many times due to bandwidth change/etc. and we're only interested in transport/connectivity changes
• Unregister the network callback when the SDK is closing
• Cache ConnectivityManager instance too (it should be safe to cache once per process as it's not dependant on any particular Context)

Ran a test with perfetto to count the number of binder calls, and these are the results:

• Send app to background
• Freeze it
• Turn wifi on and off 5 times,
• Unfreeze it back

Before (83 binder calls from SentryExecService)

After (5 binder calls from SentryExecService)

💡 Motivation and Context

Fixes #4200

💚 How did you test it?

Manually + automated

📝 Checklist

• 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.

🔮 Next steps

• Refactor NetworkBreadcrumbsIntegration so we register only one callback in AndroidConnectionStatusProvider and multiplex it
• Register/unregister connectivity callback in foreground/background similar to SystemEvents integration

[romtsn]

could drop this log call, but I thought it might be very useful to investigate potential issues. Under the hood getConnectionStatus and getConnectionType are very lightweight for a cache NetworkCapabilities instance, they just do bitmask operations to get the transport and capability

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	321.63 ms	369.32 ms	47.69 ms
Size	1.58 MiB	2.09 MiB	521.11 KiB

Previous results on branch: rz/perf/less-ipc

Startup times

Revision	Plain	With Sentry	Diff
6ef06c6	383.29 ms	403.25 ms	19.96 ms
91ac06a	386.02 ms	407.53 ms	21.51 ms

App size

Revision	Plain	With Sentry	Diff
6ef06c6	1.58 MiB	2.09 MiB	520.53 KiB
91ac06a	1.58 MiB	2.09 MiB	520.52 KiB

[markushi]

Nice! I've left a nit about the transports, but looks good otherwise!

[cursor]

Bug: Static Array Mutation Causes Network Capability Inconsistency

The static final capabilities array is mutated in the AndroidConnectionStatusProvider constructor based on instance-specific SDK versions. This creates a race condition where multiple instances, particularly those with different API levels, overwrite the shared static array, leading to inconsistent and incorrect network capability checks across all instances.

Locations (1)

• sentry-android-core/src/main/java/io/sentry/android/core/internal/util/AndroidConnectionStatusProvider.java#L54-L78

[romtsn]

While there might be multiple SDK instances running at a time, it's not possible for them to run on different API levels at the same time, because the device can only target one API level at a time.