feat(anr): Profile main thread when ANR and report ANR profiles to Sentry

[markushi]

📜 Description

Adds ANR (Application Not Responding) profiling integration that profiles the main thread when an ANR is detected and reports the captured profiles to Sentry.

Key Changes:

• New AnrProfilingIntegration to capture profiles during ANR events
• AnrProfileManager to manage ANR profile lifecycle
• AnrCulpritIdentifier to identify the culprit code causing ANR
• Stack trace and profile aggregation utilities
• Added comprehensive tests for ANR profiling functionality

💡 Motivation and Context

This feature enables better ANR diagnostics by capturing profiling data at the time of ANR detection, allowing developers to identify performance bottlenecks and problematic code paths causing application hangs.

💚 How did you test it?

• Unit tests for AnrCulpritIdentifier with various stack trace scenarios
• Integration tests for AnrProfilingIntegration
• Profile manager lifecycle tests
• Stack trace converter tests

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

🔮 Next steps

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against cee86fc

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	322.67 ms	380.85 ms	58.18 ms
Size	1.58 MiB	2.13 MiB	562.64 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
f634d01	359.58 ms	433.88 ms	74.30 ms
9fbb112	401.87 ms	515.87 ms	114.00 ms
d5a29b6	298.62 ms	391.78 ms	93.16 ms
bbc35bb	298.53 ms	372.17 ms	73.64 ms
b3d8889	420.46 ms	453.71 ms	33.26 ms
a5ab36f	320.47 ms	389.77 ms	69.30 ms
ee747ae	405.43 ms	485.70 ms	80.28 ms
951caf7	323.66 ms	392.82 ms	69.16 ms
b6702b0	395.86 ms	409.98 ms	14.12 ms
27d7cf8	369.82 ms	422.62 ms	52.80 ms

App size

Revision	Plain	With Sentry	Diff
f634d01	1.58 MiB	2.10 MiB	533.40 KiB
9fbb112	1.58 MiB	2.11 MiB	539.18 KiB
d5a29b6	1.58 MiB	2.12 MiB	549.37 KiB
bbc35bb	1.58 MiB	2.12 MiB	553.01 KiB
b3d8889	1.58 MiB	2.10 MiB	535.07 KiB
a5ab36f	1.58 MiB	2.12 MiB	555.26 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
951caf7	1.58 MiB	2.13 MiB	558.77 KiB
b6702b0	1.58 MiB	2.12 MiB	551.79 KiB
27d7cf8	1.58 MiB	2.12 MiB	549.42 KiB

Previous results on branch: markushi/feat/anr-profiling

Startup times

Revision	Plain	With Sentry	Diff
b238cff	332.00 ms	401.47 ms	69.47 ms
184b846	276.09 ms	351.65 ms	75.56 ms

App size

Revision	Plain	With Sentry	Diff
b238cff	1.58 MiB	2.13 MiB	562.66 KiB
184b846	1.58 MiB	2.13 MiB	558.70 KiB

[cursor]

Bug: Stack trace file name serialization loses null distinction

When serializing stack trace elements, StringUtils.getOrEmpty(element.getFileName()) converts null file names to empty strings. After deserialization, these become actual empty strings instead of null. In StackTraceConverter.createFrameSignature(), Java string concatenation produces different results for null vs "" - a null file name produces "Class#method#null#10" while an empty string produces "Class#method##10". This causes the frame deduplication logic to treat identical frames (especially native methods which have null file names) as different after a round-trip through persistence, resulting in duplicate frames in the profile.

Additional Locations (1)

• sentry-android-core/src/main/java/io/sentry/android/core/anr/StackTraceConverter.java#L102-L111

 

[cursor]

Bug: Missing listener removal in close method

The close() method registers itself as an AppStateListener via addAppStateListener(this) in register() but never calls AppState.getInstance().removeAppStateListener(this) when closing. Other integrations in the codebase that implement AppStateListener (like SystemEventsBreadcrumbsIntegration and AndroidConnectionStatusProvider) consistently remove themselves in their close() methods. This omission causes the integration object to remain referenced in the listener list after closure, creating a minor resource leak where the closed integration continues receiving (and ignoring) lifecycle callbacks.