Skip to content

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

Merged
buenaflor merged 69 commits into
feat/extend-app-startfrom
feat/app-start-extension-materialize
Jul 6, 2026
Merged

feat(extend-app-start): [3/4] Eagerly create the extended app start transaction#5608
buenaflor merged 69 commits into
feat/extend-app-startfrom
feat/app-start-extension-materialize

Conversation

@buenaflor

@buenaflor buenaflor commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

PR Stack (Extend App Start)


📜 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

…s wiring

Introduces the @ApiStatus.Internal IAppStartExtender contract (extendAppStart /
finishAppStart / getExtendedAppStartSpan) and a NoOp default, wired into
SentryOptions. This is the naming-stable core bridge for the app start
extension API; it is inert (returns NoOpSpan / no-ops) until the Android
implementation and public Sentry facade land later in the stack.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jun 23, 2026

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

Generated by 🚫 dangerJS against c553a7a

@sentry

sentry Bot commented Jun 23, 2026

Copy link
Copy Markdown

📲 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

github-actions Bot commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

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
ca0c0cf 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
ca0c0cf 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
44c06ea 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
44c06ea 0 B 0 B 0 B

…ix test name typo

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@buenaflor buenaflor force-pushed the feat/app-start-extension-android branch from 54be119 to d2b96ad Compare June 24, 2026 10:47
@buenaflor buenaflor force-pushed the feat/app-start-extension-materialize branch from 0f8ee4d to 5dfb0e1 Compare June 24, 2026 23:28
@buenaflor buenaflor force-pushed the feat/app-start-extension-materialize branch from 5dfb0e1 to 0bd259a Compare June 25, 2026 09:59
@buenaflor buenaflor changed the title feat(extend-app-start): [3/4] Materialize extended app start span and extend the vital feat(extend-app-start): [3/4] Eagerly create the extended app start transaction Jun 25, 2026
@buenaflor buenaflor force-pushed the feat/app-start-extension-android branch from 5dd39af to 3bc1643 Compare June 25, 2026 11:07
@buenaflor buenaflor force-pushed the feat/app-start-extension-materialize branch from 0bd259a to 0b6ada0 Compare June 25, 2026 11:07
@buenaflor buenaflor force-pushed the feat/app-start-extension-android branch from 3bc1643 to 45f6c0b Compare June 25, 2026 11:37
@buenaflor buenaflor force-pushed the feat/app-start-extension-materialize branch 5 times, most recently from c3f3627 to cbaef2f Compare June 25, 2026 12:23
buenaflor and others added 9 commits June 25, 2026 14:27
…pStart

Mirrors sentry-cocoa's finishExtendedAppLaunch() and makes the API name explicit
about finishing the *extended* app start. Renames IAppStartExtender.finishAppStart()
and the NoOpAppStartExtender implementation.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ndroid extender

Replaces the AppStartMetrics IAppStartExtender implementation and the deferred
ExtendedAppStartSpan with a focused, lock-guarded AppStartExtension that owns the
eager App Start transaction and extended span. AppStartMetrics now only holds the
component and exposes isAppStartWindowOpen(). Inert until 3/4 registers the listener.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ead of static scope lookup

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… instead of a callback

The listener now returns the created transaction+span (or null to decline)
rather than calling back into onExtended() while extendAppStart() holds the
lock. This removes the re-entrant lock acquisition and the A->B->A round trip,
collapsing two public methods into one linear flow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…o clear

Drop comments that restate code or annotate omissions (region markers, getter
javadoc, the reset call-site comment, the ExtendedAppStart/isActive docs). Rename
AppStartExtension.reset() to clear() to match its owner AppStartMetrics.clear().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ting it

The extension logs only two warnings, both on rare guard paths in extendAppStart().
Inline Sentry.getCurrentScopes().getOptions().getLogger() at those sites instead of
holding a logger field set at init, dropping the field, setLogger(), and the
AndroidOptionsInitializer wiring. extendAppStart() runs post-init, so the lookup
always yields the configured logger.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…tartExtension

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…mments

Drop finishTransaction's javadoc (trivial body; it described caller context and
waitForChildren behavior configured elsewhere) and reduce getExtendedEndTime's
javadoc to a single inline note on the only non-obvious branch (deadline suppression).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…o finishExtendedAppStart

Implements the renamed IAppStartExtender.finishExtendedAppStart().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
buenaflor and others added 4 commits June 29, 2026 11:32
The test names describe the scenarios; the inline comments restated them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Move these component accessors into the component-extraction PR (they were
introduced later in the wiring PR). Keeps the full AppStartExtension surface
and its unit tests together here; the wiring PR only consumes them. Inert on
its own. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
buenaflor and others added 8 commits June 29, 2026 14:04
It is written without a lock in onAppStartSpansSent() and read across threads in canExtendAppStart() (via extendAppStart()), with no happens-before edge. volatile guarantees visibility, matching the AtomicInteger/AtomicBoolean siblings in the same check.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…transaction

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… inactive

Mirrors Sentry.getSpan(): the extender reports null when there is no active extended span instead of a NoOpSpan, so callers can tell there is no span running.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…dAppStartSpan when inactive

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…dAppStartSpan is nullable

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The get-then-clear of the app start sampling decision in
onExtendAppStartRequested looks redundant without context. Document
that the decision is pre-rolled on the previous run, forces the eager
app.start transaction's sampling and profiler binding, and must be
cleared so the first ui.load can't also claim it.

Co-Authored-By: Claude <noreply@anthropic.com>
…ager extension finishes

The eager extendAppStart path persists trace headers so a later
ui.load can continue the app.start trace, but never recorded the app
start end time - that was only set on the headless path. If the
extended transaction finished (user finish or deadline) before any
activity, the first ui.load treated the continuation window as
unbounded and joined the completed app-start trace no matter how much
later it started.

Persist the transaction's finish date via the transaction finished
callback, which covers every finish path (finishExtendedAppStart,
first frame, deadline), so the existing continuation window check
bounds the extend path the same way it bounds the headless one.

Co-Authored-By: Claude <noreply@anthropic.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Fix All in Cursor

❌ 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 romtsn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

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?

👍

buenaflor and others added 2 commits July 3, 2026 12:10
…ension is active

A first activity arriving more than a minute after launch resets the
app start span to the activity create time and flips the type to warm.
While an app start extension is active this corrupts the extended
vital: the eager app.start transaction stays anchored at process start
while the measurement subtracts the reset span start, and a cold
launch gets reported under the warm key.

An active extension is the user explicitly saying the launch is still
in progress, so let it pin the launch: skip the reclassification while
the extension is active and apply the heuristic as before once it has
finished.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Base automatically changed from feat/app-start-extension-android to feat/extend-app-start July 6, 2026 13:47
…/app-start-extension-materialize

# Conflicts:
#	sentry-android-core/src/test/java/io/sentry/android/core/performance/AppStartMetricsTest.kt
#	sentry/src/main/java/io/sentry/SentryOptions.java
#	sentry/src/test/java/io/sentry/SentryOptionsTest.kt
@buenaflor buenaflor merged commit d4fca2d into feat/extend-app-start Jul 6, 2026
26 of 29 checks passed
@buenaflor buenaflor deleted the feat/app-start-extension-materialize branch July 6, 2026 14:48
buenaflor added a commit that referenced this pull request Jul 7, 2026
* collection: extend app start

* changelog

* feat(extend-app-start): [1/4] Add IAppStartExtender bridge (#5605)

* feat(extend-app-start): Add IAppStartExtender bridge and SentryOptions wiring

Introduces the @ApiStatus.Internal IAppStartExtender contract (extendAppStart /
finishAppStart / getExtendedAppStartSpan) and a NoOp default, wired into
SentryOptions. This is the naming-stable core bridge for the app start
extension API; it is inert (returns NoOpSpan / no-ops) until the Android
implementation and public Sentry facade land later in the stack.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Annotate NoOpAppStartExtender internal and fix test name typo

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename finishAppStart to finishExtendedAppStart

Mirrors sentry-cocoa's finishExtendedAppLaunch() and makes the API name explicit
about finishing the *extended* app start. Renames IAppStartExtender.finishAppStart()
and the NoOpAppStartExtender implementation.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from getExtendedAppStartSpan when inactive

Mirrors Sentry.getSpan(): the extender reports null when there is no active extended span instead of a NoOpSpan, so callers can tell there is no span running.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Remove NoOpAppStartExtenderTest per PR review

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(extend-app-start): Guard setAppStartExtender against null

Match the NoOp-fallback convention used by other SentryOptions setters:
accept a @nullable argument and coalesce to NoOpAppStartExtender so the
@NotNull field and getter can never be nulled out.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Use setter method for appStartExtender

The @nullable setter and @NotNull getter no longer form a Kotlin
mutable property, so use setAppStartExtender(...) instead of the
property-assignment syntax (matches setTransportFactory/setReplayController).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* feat(extend-app-start): [2/4] Extract AppStartExtension component (#5606)

* feat(extend-app-start): Add IAppStartExtender bridge and SentryOptions wiring

Introduces the @ApiStatus.Internal IAppStartExtender contract (extendAppStart /
finishAppStart / getExtendedAppStartSpan) and a NoOp default, wired into
SentryOptions. This is the naming-stable core bridge for the app start
extension API; it is inert (returns NoOpSpan / no-ops) until the Android
implementation and public Sentry facade land later in the stack.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Annotate NoOpAppStartExtender internal and fix test name typo

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename finishAppStart to finishExtendedAppStart

Mirrors sentry-cocoa's finishExtendedAppLaunch() and makes the API name explicit
about finishing the *extended* app start. Renames IAppStartExtender.finishAppStart()
and the NoOpAppStartExtender implementation.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Extract AppStartExtension component for the Android extender

Replaces the AppStartMetrics IAppStartExtender implementation and the deferred
ExtendedAppStartSpan with a focused, lock-guarded AppStartExtension that owns the
eager App Start transaction and extended span. AppStartMetrics now only holds the
component and exposes isAppStartWindowOpen(). Inert until 3/4 registers the listener.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Inject logger into AppStartExtension instead of static scope lookup

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Return ExtendedAppStart from the listener instead of a callback

The listener now returns the created transaction+span (or null to decline)
rather than calling back into onExtended() while extendAppStart() holds the
lock. This removes the re-entrant lock acquisition and the A->B->A round trip,
collapsing two public methods into one linear flow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Remove redundant comments and rename reset to clear

Drop comments that restate code or annotate omissions (region markers, getter
javadoc, the reset call-site comment, the ExtendedAppStart/isActive docs). Rename
AppStartExtension.reset() to clear() to match its owner AppStartMetrics.clear().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Inline the logger lookup instead of injecting it

The extension logs only two warnings, both on rare guard paths in extendAppStart().
Inline Sentry.getCurrentScopes().getOptions().getLogger() at those sites instead of
holding a logger field set at init, dropping the field, setLogger(), and the
AndroidOptionsInitializer wiring. extendAppStart() runs post-init, so the lookup
always yields the configured logger.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the class and listener javadocs on AppStartExtension

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Trim finishTransaction/getExtendedEndTime comments

Drop finishTransaction's javadoc (trivial body; it described caller context and
waitForChildren behavior configured elsewhere) and reduce getExtendedEndTime's
javadoc to a single inline note on the only non-obvious branch (deadline suppression).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename AppStartExtension.finishAppStart to finishExtendedAppStart

Implements the renamed IAppStartExtender.finishExtendedAppStart().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the redundant foreground-check comment on extendAppStart

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-value getAppStartExtension test and trim comments

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-op finishExtendedAppStart test

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Read the extended span finish date, not its finished flag

getExtendedEndTime() gated on span.isFinished(), but finishing the extended
span completes the waitForChildren transaction and runs the event processor
re-entrantly within finishExtendedAppStart(), before the span's finished flag
is set. The processor then saw an unfinished span and dropped the app start
measurement whenever the extension finished after the first frame. Read
getFinishDate() (set before the finish callback) instead, which also keeps the
extended end controllable in tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): End the extended transaction at the extended span end

When the extended span finished after the timestamp passed to
finishTransaction() but before that call ran (e.g. a synchronous extension in a
headless start, where finishTransaction runs later at main-thread idle),
waitForChildren had nothing left to wait for and the transaction kept the
earlier passed timestamp. The extended span then ended after the transaction,
and the app start vital exceeded the transaction duration. Finish at
max(endTimestamp, extended span finish date) so the span is contained and the
duration matches the vital.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Guard extendAppStartListener with the lock

The setter wrote the field without synchronization while extendAppStart()
reads it under the lock, leaving no happens-before edge. Acquire the same
lock in the setter, consistent with the rest of the class's mutable state.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim verbose finishTransaction comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Read finish date in getExtendedAppStartSpan

Finishing the extended span runs the event processor re-entrantly (via
the waitForChildren transaction) before the span's isFinished() flag is
set, while the finish timestamp is already in place. Reading isFinished()
could therefore hand out a span that is already finishing. Switch to
getFinishDate() == null, matching getExtendedEndTime().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim duplicated reentrancy comment in getExtendedAppStartSpan

Replace the repeated reentrancy explanation with a cross-reference to
getExtendedEndTime(), which holds the canonical version.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Keep trimmed reentrancy comment within line length

Single-line form fits the 100-char limit so spotless leaves it unwrapped.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Reword getExtendedAppStartSpan reentrancy comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename isAppStartWindowOpen to canExtendAppStart

The predicate has a single consumer — the extend gate in
AppStartExtension — so name it for that intent. Also drop the
self-evident max-end comment in finishTransaction. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop redundant getExtendedAppStartSpan finished test

After getExtendedAppStartSpan switched to getFinishDate(), the
"after the span finished" case exercises the same branch as the
reentrancy test (finishDate set -> NoOp); the isFinished stub was inert.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Add setData and isExtended to AppStartExtension

Move these component accessors into the component-extraction PR (they were
introduced later in the wiring PR). Keeps the full AppStartExtension surface
and its unit tests together here; the wiring PR only consumes them. Inert on
its own. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Make shouldSendStartMeasurements volatile

It is written without a lock in onAppStartSpansSent() and read across threads in canExtendAppStart() (via extendAppStart()), with no happens-before edge. volatile guarantees visibility, matching the AtomicInteger/AtomicBoolean siblings in the same check.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(extend-app-start): Explain why AppStartExtension holds span and transaction

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from getExtendedAppStartSpan when inactive

Mirrors Sentry.getSpan(): the extender reports null when there is no active extended span instead of a NoOpSpan, so callers can tell there is no span running.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from AppStartExtension.getExtendedAppStartSpan when inactive

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Use setter method for appStartExtender

The @nullable setter and @NotNull getter no longer form a Kotlin
mutable property, so use setAppStartExtender(...) instead of the
property-assignment syntax (matches setTransportFactory/setReplayController).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

* feat(extend-app-start): Add IAppStartExtender bridge and SentryOptions wiring

Introduces the @ApiStatus.Internal IAppStartExtender contract (extendAppStart /
finishAppStart / getExtendedAppStartSpan) and a NoOp default, wired into
SentryOptions. This is the naming-stable core bridge for the app start
extension API; it is inert (returns NoOpSpan / no-ops) until the Android
implementation and public Sentry facade land later in the stack.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Annotate NoOpAppStartExtender internal and fix test name typo

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename finishAppStart to finishExtendedAppStart

Mirrors sentry-cocoa's finishExtendedAppLaunch() and makes the API name explicit
about finishing the *extended* app start. Renames IAppStartExtender.finishAppStart()
and the NoOpAppStartExtender implementation.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Extract AppStartExtension component for the Android extender

Replaces the AppStartMetrics IAppStartExtender implementation and the deferred
ExtendedAppStartSpan with a focused, lock-guarded AppStartExtension that owns the
eager App Start transaction and extended span. AppStartMetrics now only holds the
component and exposes isAppStartWindowOpen(). Inert until 3/4 registers the listener.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Inject logger into AppStartExtension instead of static scope lookup

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Return ExtendedAppStart from the listener instead of a callback

The listener now returns the created transaction+span (or null to decline)
rather than calling back into onExtended() while extendAppStart() holds the
lock. This removes the re-entrant lock acquisition and the A->B->A round trip,
collapsing two public methods into one linear flow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Remove redundant comments and rename reset to clear

Drop comments that restate code or annotate omissions (region markers, getter
javadoc, the reset call-site comment, the ExtendedAppStart/isActive docs). Rename
AppStartExtension.reset() to clear() to match its owner AppStartMetrics.clear().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Inline the logger lookup instead of injecting it

The extension logs only two warnings, both on rare guard paths in extendAppStart().
Inline Sentry.getCurrentScopes().getOptions().getLogger() at those sites instead of
holding a logger field set at init, dropping the field, setLogger(), and the
AndroidOptionsInitializer wiring. extendAppStart() runs post-init, so the lookup
always yields the configured logger.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the class and listener javadocs on AppStartExtension

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Trim finishTransaction/getExtendedEndTime comments

Drop finishTransaction's javadoc (trivial body; it described caller context and
waitForChildren behavior configured elsewhere) and reduce getExtendedEndTime's
javadoc to a single inline note on the only non-obvious branch (deadline suppression).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename AppStartExtension.finishAppStart to finishExtendedAppStart

Implements the renamed IAppStartExtender.finishExtendedAppStart().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Eagerly create the extended App Start transaction (standalone-only)

Registers an extend-listener on AppStartExtension that eagerly creates the
standalone app.start transaction + extended child span in Application.onCreate,
held open via waitForChildren until Sentry.finishAppStart() or the deadline. The
first activity continues the eager trace into ui.load (attaching the screen so it
stays a foreground app.start) instead of creating a second app.start; headless
finishes the eager txn. The app start vital is max(natural, extended) so an early
finish never shortens it, and is suppressed on deadline. Standalone-only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the redundant foreground-check comment on extendAppStart

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Replace the no-op finish test with isExtended coverage

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-value getAppStartExtension test and trim comments

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the redundant foreground-check comment on extendAppStart

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-value getAppStartExtension test and trim comments

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-op finishExtendedAppStart test

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Trim and de-duplicate comments in the eager app start path

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Clarify the extensionActive comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Read the extended span finish date, not its finished flag

getExtendedEndTime() gated on span.isFinished(), but finishing the extended
span completes the waitForChildren transaction and runs the event processor
re-entrantly within finishExtendedAppStart(), before the span's finished flag
is set. The processor then saw an unfinished span and dropped the app start
measurement whenever the extension finished after the first frame. Read
getFinishDate() (set before the finish callback) instead, which also keeps the
extended end controllable in tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): End the extended transaction at the extended span end

When the extended span finished after the timestamp passed to
finishTransaction() but before that call ran (e.g. a synchronous extension in a
headless start, where finishTransaction runs later at main-thread idle),
waitForChildren had nothing left to wait for and the transaction kept the
earlier passed timestamp. The extended span then ended after the transaction,
and the app start vital exceeded the transaction duration. Finish at
max(endTimestamp, extended span finish date) so the span is contained and the
duration matches the vital.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* ref(extend-app-start): Rename extended app start span op to app.start.extended

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Guard extendAppStartListener with the lock

The setter wrote the field without synchronization while extendAppStart()
reads it under the lock, leaving no happens-before edge. Acquire the same
lock in the setter, consistent with the rest of the class's mutable state.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Fix headless app start end time and duplicate txn

Two issues in onHeadlessAppStart for extended starts:
- The extended branch finished the eager transaction but never persisted
  appStartEndTime, leaving the continuation window unbounded so a later
  activity would wrongly continue the stale trace. Persist it on all paths.
- The branch only checked isActive(), so if the extension already finished
  (finishExtendedAppStart or the deadline) before the headless idle ran, a
  second, empty standalone app.start was created. Guard on
  shouldSendStartMeasurements to avoid the duplicate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim low-value comments in the headless fix

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Drop redundant extend-listener comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim redundant comments in onActivityCreated

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Remove explanatory comments in app start paths

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Consume stored app start trace on the extension path

The first activity continuing an extended app.start did not clear the stored
trace headers (only the headless-follow path did), so a later activity saw
them and wrongly reused the finished app start trace. Clear them on the
extension path too.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Only the launch activity attaches the app start screen

While the extension was open, every activity's onActivityCreated re-attached
app.vitals.start.screen to the eager app.start, so a second activity opened
before finishExtendedAppStart() overwrote the launch screen. Gate the attach
on isAppStart so only the launch activity sets it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Format code

* style(extend-app-start): Trim verbose finishTransaction comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim verbose comments in app start paths

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Read finish date in getExtendedAppStartSpan

Finishing the extended span runs the event processor re-entrantly (via
the waitForChildren transaction) before the span's isFinished() flag is
set, while the finish timestamp is already in place. Reading isFinished()
could therefore hand out a span that is already finishing. Switch to
getFinishDate() == null, matching getExtendedEndTime().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim duplicated reentrancy comment in getExtendedAppStartSpan

Replace the repeated reentrancy explanation with a cross-reference to
getExtendedEndTime(), which holds the canonical version.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Keep trimmed reentrancy comment within line length

Single-line form fits the 100-char limit so spotless leaves it unwrapped.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Drop two line-narrating test comments

Remove comments that restated the adjacent test code (the eager
extendAppStart call and the second-activity open).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Reword getExtendedAppStartSpan reentrancy comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename isAppStartWindowOpen to canExtendAppStart

The predicate has a single consumer — the extend gate in
AppStartExtension — so name it for that intent. Also drop the
self-evident max-end comment in finishTransaction. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop redundant getExtendedAppStartSpan finished test

After getExtendedAppStartSpan switched to getFinishDate(), the
"after the span finished" case exercises the same branch as the
reentrancy test (finishDate set -> NoOp); the isFinished stub was inert.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop narrating comments from app start tests

The test names describe the scenarios; the inline comments restated them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Add setData and isExtended to AppStartExtension

Move these component accessors into the component-extraction PR (they were
introduced later in the wiring PR). Keeps the full AppStartExtension surface
and its unit tests together here; the wiring PR only consumes them. Inert on
its own. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Name app start branching booleans by intent

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Make shouldSendStartMeasurements volatile

It is written without a lock in onAppStartSpansSent() and read across threads in canExtendAppStart() (via extendAppStart()), with no happens-before edge. volatile guarantees visibility, matching the AtomicInteger/AtomicBoolean siblings in the same check.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(extend-app-start): Explain why AppStartExtension holds span and transaction

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from getExtendedAppStartSpan when inactive

Mirrors Sentry.getSpan(): the extender reports null when there is no active extended span instead of a NoOpSpan, so callers can tell there is no span running.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from AppStartExtension.getExtendedAppStartSpan when inactive

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Assert null extended span now that getExtendedAppStartSpan is nullable

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(extend-app-start): Explain single-use app start sampling decision

The get-then-clear of the app start sampling decision in
onExtendAppStartRequested looks redundant without context. Document
that the decision is pre-rolled on the previous run, forces the eager
app.start transaction's sampling and profiler binding, and must be
cleared so the first ui.load can't also claim it.

Co-Authored-By: Claude <noreply@anthropic.com>

* fix(extend-app-start): Bound the trace continuation window after an eager extension finishes

The eager extendAppStart path persists trace headers so a later
ui.load can continue the app.start trace, but never recorded the app
start end time - that was only set on the headless path. If the
extended transaction finished (user finish or deadline) before any
activity, the first ui.load treated the continuation window as
unbounded and joined the completed app-start trace no matter how much
later it started.

Persist the transaction's finish date via the transaction finished
callback, which covers every finish path (finishExtendedAppStart,
first frame, deadline), so the existing continuation window check
bounds the extend path the same way it bounds the headless one.

Co-Authored-By: Claude <noreply@anthropic.com>

* fix(extend-app-start): Skip warm-start reclassification while the extension is active

A first activity arriving more than a minute after launch resets the
app start span to the activity create time and flips the type to warm.
While an app start extension is active this corrupts the extended
vital: the eager app.start transaction stays anchored at process start
while the measurement subtracts the reset span start, and a cold
launch gets reported under the warm key.

An active extension is the user explicitly saying the launch is still
in progress, so let it pin the launch: skip the reclassification while
the extension is active and apply the heuristic as before once it has
finished.

Co-Authored-By: Claude <noreply@anthropic.com>

* test(extend-app-start): Remove NoOpAppStartExtenderTest per PR review

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io>

* feat(extend-app-start): [4/4] Add public Sentry app start extension API and update example app (#5628)

* feat(extend-app-start): Add IAppStartExtender bridge and SentryOptions wiring

Introduces the @ApiStatus.Internal IAppStartExtender contract (extendAppStart /
finishAppStart / getExtendedAppStartSpan) and a NoOp default, wired into
SentryOptions. This is the naming-stable core bridge for the app start
extension API; it is inert (returns NoOpSpan / no-ops) until the Android
implementation and public Sentry facade land later in the stack.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Annotate NoOpAppStartExtender internal and fix test name typo

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename finishAppStart to finishExtendedAppStart

Mirrors sentry-cocoa's finishExtendedAppLaunch() and makes the API name explicit
about finishing the *extended* app start. Renames IAppStartExtender.finishAppStart()
and the NoOpAppStartExtender implementation.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Extract AppStartExtension component for the Android extender

Replaces the AppStartMetrics IAppStartExtender implementation and the deferred
ExtendedAppStartSpan with a focused, lock-guarded AppStartExtension that owns the
eager App Start transaction and extended span. AppStartMetrics now only holds the
component and exposes isAppStartWindowOpen(). Inert until 3/4 registers the listener.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Inject logger into AppStartExtension instead of static scope lookup

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Return ExtendedAppStart from the listener instead of a callback

The listener now returns the created transaction+span (or null to decline)
rather than calling back into onExtended() while extendAppStart() holds the
lock. This removes the re-entrant lock acquisition and the A->B->A round trip,
collapsing two public methods into one linear flow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Remove redundant comments and rename reset to clear

Drop comments that restate code or annotate omissions (region markers, getter
javadoc, the reset call-site comment, the ExtendedAppStart/isActive docs). Rename
AppStartExtension.reset() to clear() to match its owner AppStartMetrics.clear().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Inline the logger lookup instead of injecting it

The extension logs only two warnings, both on rare guard paths in extendAppStart().
Inline Sentry.getCurrentScopes().getOptions().getLogger() at those sites instead of
holding a logger field set at init, dropping the field, setLogger(), and the
AndroidOptionsInitializer wiring. extendAppStart() runs post-init, so the lookup
always yields the configured logger.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the class and listener javadocs on AppStartExtension

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Trim finishTransaction/getExtendedEndTime comments

Drop finishTransaction's javadoc (trivial body; it described caller context and
waitForChildren behavior configured elsewhere) and reduce getExtendedEndTime's
javadoc to a single inline note on the only non-obvious branch (deadline suppression).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename AppStartExtension.finishAppStart to finishExtendedAppStart

Implements the renamed IAppStartExtender.finishExtendedAppStart().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Eagerly create the extended App Start transaction (standalone-only)

Registers an extend-listener on AppStartExtension that eagerly creates the
standalone app.start transaction + extended child span in Application.onCreate,
held open via waitForChildren until Sentry.finishAppStart() or the deadline. The
first activity continues the eager trace into ui.load (attaching the screen so it
stays a foreground app.start) instead of creating a second app.start; headless
finishes the eager txn. The app start vital is max(natural, extended) so an early
finish never shortens it, and is suppressed on deadline. Standalone-only.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Add public Sentry app start extension API

Static bridge delegating to options.getAppStartExtender(): extendAppStart(),
finishAppStart(), getExtendedAppStartSpan(). No-op when the SDK is disabled or the
platform provides no app start extender. Completes the extend app start feature (4/4).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the redundant foreground-check comment on extendAppStart

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Replace the no-op finish test with isExtended coverage

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-value getAppStartExtension test and trim comments

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Drop the redundant foreground-check comment on extendAppStart

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-value getAppStartExtension test and trim comments

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop the no-op finishExtendedAppStart test

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Trim and de-duplicate comments in the eager app start path

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(extend-app-start): Clarify the extensionActive comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Show extending the app start in the Android sample

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Read the extended span finish date, not its finished flag

getExtendedEndTime() gated on span.isFinished(), but finishing the extended
span completes the waitForChildren transaction and runs the event processor
re-entrantly within finishExtendedAppStart(), before the span's finished flag
is set. The processor then saw an unfinished span and dropped the app start
measurement whenever the extension finished after the first frame. Read
getFinishDate() (set before the finish callback) instead, which also keeps the
extended end controllable in tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): End the extended transaction at the extended span end

When the extended span finished after the timestamp passed to
finishTransaction() but before that call ran (e.g. a synchronous extension in a
headless start, where finishTransaction runs later at main-thread idle),
waitForChildren had nothing left to wait for and the transaction kept the
earlier passed timestamp. The extended span then ended after the transaction,
and the app start vital exceeded the transaction duration. Finish at
max(endTimestamp, extended span finish date) so the span is contained and the
duration matches the vital.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* ref(extend-app-start): Rename extended app start span op to app.start.extended

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Guard extendAppStartListener with the lock

The setter wrote the field without synchronization while extendAppStart()
reads it under the lock, leaving no happens-before edge. Acquire the same
lock in the setter, consistent with the rest of the class's mutable state.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Fix headless app start end time and duplicate txn

Two issues in onHeadlessAppStart for extended starts:
- The extended branch finished the eager transaction but never persisted
  appStartEndTime, leaving the continuation window unbounded so a later
  activity would wrongly continue the stale trace. Persist it on all paths.
- The branch only checked isActive(), so if the extension already finished
  (finishExtendedAppStart or the deadline) before the headless idle ran, a
  second, empty standalone app.start was created. Guard on
  shouldSendStartMeasurements to avoid the duplicate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim low-value comments in the headless fix

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Drop redundant extend-listener comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim redundant comments in onActivityCreated

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Remove explanatory comments in app start paths

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Consume stored app start trace on the extension path

The first activity continuing an extended app.start did not clear the stored
trace headers (only the headless-follow path did), so a later activity saw
them and wrongly reused the finished app start trace. Clear them on the
extension path too.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Only the launch activity attaches the app start screen

While the extension was open, every activity's onActivityCreated re-attached
app.vitals.start.screen to the eager app.start, so a second activity opened
before finishExtendedAppStart() overwrote the launch screen. Gate the attach
on isAppStart so only the launch activity sets it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Format code

* Format code

* style(extend-app-start): Trim verbose finishTransaction comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim verbose comments in app start paths

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Read finish date in getExtendedAppStartSpan

Finishing the extended span runs the event processor re-entrantly (via
the waitForChildren transaction) before the span's isFinished() flag is
set, while the finish timestamp is already in place. Reading isFinished()
could therefore hand out a span that is already finishing. Switch to
getFinishDate() == null, matching getExtendedEndTime().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Trim duplicated reentrancy comment in getExtendedAppStartSpan

Replace the repeated reentrancy explanation with a cross-reference to
getExtendedEndTime(), which holds the canonical version.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Keep trimmed reentrancy comment within line length

Single-line form fits the 100-char limit so spotless leaves it unwrapped.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Drop two line-narrating test comments

Remove comments that restated the adjacent test code (the eager
extendAppStart call and the second-activity open).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(extend-app-start): Reword getExtendedAppStartSpan reentrancy comment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Rename isAppStartWindowOpen to canExtendAppStart

The predicate has a single consumer — the extend gate in
AppStartExtension — so name it for that intent. Also drop the
self-evident max-end comment in finishTransaction. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop redundant getExtendedAppStartSpan finished test

After getExtendedAppStartSpan switched to getFinishDate(), the
"after the span finished" case exercises the same branch as the
reentrancy test (finishDate set -> NoOp); the isFinished stub was inert.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Drop narrating comments from app start tests

The test names describe the scenarios; the inline comments restated them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Add setData and isExtended to AppStartExtension

Move these component accessors into the component-extraction PR (they were
introduced later in the wiring PR). Keeps the full AppStartExtension surface
and its unit tests together here; the wiring PR only consumes them. Inert on
its own. Regenerated apiDump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(extend-app-start): Name app start branching booleans by intent

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(extend-app-start): Make shouldSendStartMeasurements volatile

It is written without a lock in onAppStartSpansSent() and read across threads in canExtendAppStart() (via extendAppStart()), with no happens-before edge. volatile guarantees visibility, matching the AtomicInteger/AtomicBoolean siblings in the same check.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(extend-app-start): Explain why AppStartExtension holds span and transaction

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from getExtendedAppStartSpan when inactive

Mirrors Sentry.getSpan(): the extender reports null when there is no active extended span instead of a NoOpSpan, so callers can tell there is no span running.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Return null from AppStartExtension.getExtendedAppStartSpan when inactive

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(extend-app-start): Assert null extended span now that getExtendedAppStartSpan is nullable

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(extend-app-start): Make Sentry.getExtendedAppStartSpan() nullable

Mirrors Sentry.getSpan(): returns null when no extension is active instead of a NoOpSpan, so callers can tell there is no span running. Sample null-checks the span.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io>

* changelog

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants