fix(android-fragment): support detach/attach navigation in fragment tracing

[romtsn]

Summary

Fixes a silent data quality issue where detach/attach tab navigation (and similar patterns) left ui.load spans open until the 30-second activity transaction deadline, producing badly inflated performance data.

Root cause

SentryFragmentLifecycleCallbacks started spans in onFragmentCreated and stopped them in onFragmentStarted (a concession to ViewPager2 which locks background fragments to STARTED). For detach/attach navigation — manual tab switching (transaction.detach(current).attach(next).commit()), ViewPager v1 with FragmentPagerAdapter, and custom navigation frameworks that preserve fragment state — onFragmentCreated is never called for off-screen fragments. Spans would hang silently until the deadline.

Fix

Three targeted changes, all leveraging the fact that startTracing / stopTracing are already idempotent:

Hook	Change	Why
onFragmentViewCreated	+startTracing	Enables narrower viewCreated → resumed span for detach/attach paths. No-op if onFragmentCreated already started a span.
onFragmentResumed	+stopTracing	Ends the span on the detach/attach path where onFragmentStarted may not fire. No-op for the normal path where onFragmentStarted already closed the span.
onFragmentViewDestroyed	+stopTracing	Failsafe: closes any span for a fragment whose view is destroyed before reaching STARTED or RESUMED.

The normal lifecycle path (onFragmentCreated → onFragmentViewCreated → onFragmentStarted → onFragmentResumed) is completely unaffected — still produces exactly one ui.load span, closed at onFragmentStarted.

What's new for customers

Apps using detach/attach navigation will now see correct, narrower ui.load spans (viewCreated → resumed) instead of timeout-inflated spans.

Tests

Five new unit tests covering:

• Detach/attach path: onFragmentViewCreated starts a span when tracing enabled
• Normal path: onFragmentViewCreated is a no-op when span already running
• Detach/attach path: onFragmentResumed stops the span
• Normal path: onFragmentResumed does not double-finish after onFragmentStarted
• Failsafe: onFragmentViewDestroyed stops a span that never reached STARTED/RESUMED

Example trace: https://sentry-sdks.sentry.io/explore/traces/trace/edb7de2bba454d70a4c13eee5bce660c/

As you can see TabFragmentB now correctly shows up after re-attaching (but wouldn't have without this fix):

Not verified

./gradlew spotlessApply apiDump could not run (no JDK in sandbox) — CI will apply formatting and regenerate .api files if needed.

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.46.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	314.90 ms	364.90 ms	50.00 ms
Size	0 B	0 B	0 B

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
1edbdfa	364.77 ms	450.29 ms	85.52 ms
a416a65	333.78 ms	410.37 ms	76.59 ms
d15471f	302.62 ms	353.84 ms	51.22 ms
22f4345	314.79 ms	375.02 ms	60.23 ms
6b019b7	343.31 ms	417.23 ms	73.91 ms
22f4345	312.78 ms	347.40 ms	34.62 ms
d217708	411.22 ms	430.86 ms	19.63 ms
319f256	315.96 ms	372.96 ms	57.00 ms
e2dce0b	308.96 ms	360.10 ms	51.14 ms
8558cac	306.16 ms	355.24 ms	49.09 ms

App size

Revision	Plain	With Sentry	Diff
1edbdfa	1.58 MiB	2.20 MiB	635.34 KiB
a416a65	1.58 MiB	2.12 MiB	555.26 KiB
d15471f	1.58 MiB	2.13 MiB	559.54 KiB
22f4345	1.58 MiB	2.29 MiB	719.83 KiB
6b019b7	0 B	0 B	0 B
22f4345	1.58 MiB	2.29 MiB	719.83 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
319f256	1.58 MiB	2.19 MiB	619.79 KiB
e2dce0b	0 B	0 B	0 B
8558cac	0 B	0 B	0 B

Previous results on branch: fix/fragment-detach-attach-tracing

Startup times

Revision	Plain	With Sentry	Diff
7966377	324.00 ms	379.38 ms	55.38 ms
c53e6fb	312.80 ms	372.79 ms	59.99 ms

App size

Revision	Plain	With Sentry	Diff
7966377	0 B	0 B	0 B
c53e6fb	0 B	0 B	0 B