feat(extend-app-start): [3/4] Eagerly create the extended app start transaction

[buenaflor]

PR Stack (Extend App Start)

• feat(extend-app-start): App start extension API #5604
• feat(extend-app-start): [1/4] Add IAppStartExtender bridge #5605
• feat(extend-app-start): [2/4] Extract AppStartExtension component #5606
• feat(extend-app-start): [3/4] Eagerly create the extended app start transaction #5608
• feat(extend-app-start): [4/4] Add public Sentry app start extension API and update example app #5628

---

📜 Description

Registers the extend-listener and wires the extension through to the trace and the vital, making the feature work end-to-end. The extension is eager and standalone-only — only the standalone app.start transaction is independent of an activity and can be created in Application.onCreate.

Class	Change
ActivityLifecycleIntegration	Registers the extend-listener, but only when enableStandaloneAppStartTracing is on (this is what makes the API standalone-only). On Sentry.extendAppStart() the listener eagerly creates the standalone app.start transaction (waitForChildren + deadline) and its app.start.extended child, and returns them as an ExtendedAppStart.
PerformanceAndroidEventProcessor	App start vital is now max(natural first-frame duration, extended end), so an early finish never shortens it. On deadline the measurement is suppressed entirely (no inflated ~30s value); spans still attach. Non-extended starts are unchanged.

Notes

• The transaction is owned by the extension, not the integration's appStartTransaction field, so per-activity cleanup can't cancel it.
• The first activity continues the eager trace into ui.load (via isActive()) instead of starting a second app.start, and attaches the screen so the foreground app.start keeps its app.vitals.start.screen.
• The first frame finishes the transaction; waitForChildren holds it open until Sentry.finishExtendedAppStart(). Headless finishes it at the headless stop time. A shared createStandaloneAppStartTransaction(...) helper backs both paths.
• The legacy deferred-span path and the non-standalone (ui.load) extension path are removed — eager creation makes them unnecessary.

💡 Motivation and Context

Part of the app start extension API stack (#5553). This is where the extension actually affects the trace and the vital, scoped to standalone app start tracing because only the standalone app.start transaction can be created eagerly in onCreate.

💚 How did you test it?

Unit tests (TDD):

• ActivityLifecycleIntegrationTest — eager app.start + extended child on extend; first activity continues the trace with no second app.start and the screen attached; standalone & headless stay open until finishExtendedAppStart(); standalone-off is a no-op; the eager txn survives activity destroy.
• PerformanceAndroidEventProcessorTest — extended end drives the cold measurement; an early finish never reports shorter than the first-frame duration; a deadline finish suppresses the measurement.

apiCheck, spotless, and the :sentry-android-core unit suite pass.

📝 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

[4/4] — add the public Sentry.extendAppStart() / Sentry.finishExtendedAppStart() / Sentry.getExtendedAppStartSpan() facade.

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

#skip-changelog

[github-actions]

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

Generated by 🚫 dangerJS against c553a7a

[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	322.02 ms	380.71 ms	58.69 ms
Size	0 B	0 B	0 B

Baseline results on branch: feat/app-start-extension-android

Startup times

Revision	Plain	With Sentry	Diff
db5be2f	311.84 ms	365.94 ms	54.10 ms
388ffc5	315.18 ms	362.43 ms	47.25 ms
d8041d7	305.32 ms	370.59 ms	65.27 ms
ca0c0cfc14d958d067e640e132d8de863dfe8eb1	318.45 ms	370.06 ms	51.61 ms
201a6fd	326.00 ms	371.92 ms	45.92 ms
b76203f	336.02 ms	403.42 ms	67.40 ms
ba0608b	319.63 ms	373.04 ms	53.41 ms
682e090	347.33 ms	427.28 ms	79.95 ms

App size

Revision	Plain	With Sentry	Diff
db5be2f	0 B	0 B	0 B
388ffc5	0 B	0 B	0 B
d8041d7	0 B	0 B	0 B
ca0c0cfc14d958d067e640e132d8de863dfe8eb1	0 B	0 B	0 B
201a6fd	0 B	0 B	0 B
b76203f	0 B	0 B	0 B
ba0608b	0 B	0 B	0 B
682e090	0 B	0 B	0 B

Previous results on branch: feat/app-start-extension-materialize

Startup times

Revision	Plain	With Sentry	Diff
69caaee	313.73 ms	373.92 ms	60.19 ms
e5800ed	318.21 ms	375.48 ms	57.27 ms
ae82ca0	381.62 ms	426.12 ms	44.51 ms
a037262	318.06 ms	364.59 ms	46.52 ms
511890d	315.38 ms	376.00 ms	60.62 ms
20bbe9a	305.48 ms	387.25 ms	81.77 ms
4451634	321.21 ms	376.21 ms	55.00 ms
3a27919	371.17 ms	447.31 ms	76.14 ms
4cf89ba	340.51 ms	416.92 ms	76.41 ms
44c06ea9f76963a0e6034503bb612c43aca71502	324.19 ms	384.88 ms	60.69 ms

App size

Revision	Plain	With Sentry	Diff
69caaee	0 B	0 B	0 B
e5800ed	0 B	0 B	0 B
ae82ca0	0 B	0 B	0 B
a037262	0 B	0 B	0 B
511890d	0 B	0 B	0 B
20bbe9a	0 B	0 B	0 B
4451634	0 B	0 B	0 B
3a27919	0 B	0 B	0 B
4cf89ba	0 B	0 B	0 B
44c06ea9f76963a0e6034503bb612c43aca71502	0 B	0 B	0 B

[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.}

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

[romtsn]

LGTM, but we really need to refactor this thing 🙈 it's just too many if-elses in here. If you got time could you task Fable to come up with nice a refactor plan maybe and create an issue out of that?

[buenaflor]

it's just too many if-elses in here

yeah :/ so many edge cases with all the different combinations, prolly some of the complexity will be gone as well once we make standalone the only way to go.

come up with nice a refactor plan maybe and create an issue out of that?

👍