* feat: Add standalone app start transaction (happy path)
Introduce experimental `enableStandaloneAppStartTracing` option that creates
a separate app start transaction instead of attaching app start as a child
span of the first activity transaction. This is the happy path only (foreground
importance, activity launch, first frame drawn as end time).
The standalone transaction shares the same trace ID as the activity transaction
but is not bound to the scope. App start measurements and child spans (process
init, content providers, application.onCreate) are attached to the standalone
transaction instead of the activity transaction.
Includes foreground importance check branching to prepare for the non-activity
launch path (next PR).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: Add non-activity app start path with end time resolution
When the app starts without launching an activity (service, broadcast
receiver, content provider), create a standalone app start transaction
with the end time determined by priority:
1. onApplicationPostCreate (Gradle plugin bytecode instrumentation)
2. ApplicationStartInfo timestamps (API 35+)
3. firstIdle - main thread idle handler (pre-API 35 fallback)
The non-activity app start transaction stores its trace ID so that if
an activity is later launched, the activity transaction reuses the same
trace ID to keep both in the same trace.
Adds OnNoActivityStartedListener callback from AppStartMetrics to
ActivityLifecycleIntegration, triggered by checkCreateTimeOnMain()
when no activity was created after Application.onCreate().
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: Support non-activity app start tracing without bytecode instrumentation
When an app is launched via broadcast receiver, service, or content provider
(no activity), detect this via Handler.post() and create a standalone app start
transaction. Resolves app start end time with priority: Gradle plugin >
ApplicationStartInfo (API 35+) > process init time. Also attaches child spans
(process init, content providers, Application.onCreate) to standalone
transactions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* refactor: Consolidate non-activity app start time-span resolution
Extract the "try appStartSpan, fall back to sdkInitTimeSpan" logic used for
standalone (non-activity) app start transactions into a new
AppStartMetrics.getAppStartTimeSpanDirect() helper, removing the duplicated
inline fallback in ActivityLifecycleIntegration and the private helper in
PerformanceAndroidEventProcessor.
Also cache the API 35+ ApplicationStartInfo on registerLifecycleCallbacks so
onAppStartSpansSent no longer re-queries ActivityManager, and simplify the
non-activity detection path to always use the main-thread IdleHandler.
Regenerates the sentry-android-core API to include method additions missed in
prior commits on this branch (standalone-app-start options, trace id accessors,
OnNoActivityStartedListener).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(samples): Register TestBroadcastReceiver in manifest
Wires up the TestBroadcastReceiver added earlier so the sample app can trigger
a non-activity cold start via `adb shell am broadcast`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(app-start): resolve standalone tracing misclassification and duplicate emission
Two pre-merge fixes for the standalone app-start tracing path introduced on
this branch (issue #5046):
- AppStartMetrics.checkCreateTimeOnMain() now defaults appStartType to COLD
when UNKNOWN with no active activities. On API < 35 (where
ApplicationStartInfo is unavailable) non-activity cold starts were stuck
at UNKNOWN, which both misclassified the standalone transaction as
App Start Warm and caused PerformanceAndroidEventProcessor.attachAppStartSpans
to early-return (dropping process.load / application.load / contentprovider.load
phase spans).
- ActivityLifecycleIntegration.onActivityPreCreated() now skips emitting a
second standalone App Start transaction when the non-activity path has
already reported the process's app start (detected via the stashed
appStartTraceId). Previously a broadcast followed by an activity launch
produced two standalone transactions (a spurious App Start Warm in addition
to the broadcast's App Start Cold), violating one-per-process semantics.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(android): refine standalone app start tracing
* chore: Update generated files
* style(core): Apply spotless formatting
* changelog
* fix(android): Use stable app start transaction name
Rename the standalone app-start transaction to a single App Start name
so cold and warm starts group consistently while preserving the app.start op.
Co-authored-by: Cursor <cursoragent@cursor.com>
* feat(android): Add standalone app start tracing
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Handle non-activity app starts below API 24
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Guard app start timestamp clock base
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Remove app start reason plumbing
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Clarify no-activity app start handling
Rename the private app start helper to reflect that it conditionally
handles non-activity starts. Keep comments and tests focused on behavior.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* docs(android): Clarify non-activity app start fallback
Explain why unresolved non-activity starts default to cold when Activity
signals or ApplicationStartInfo classification are unavailable.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Preserve legacy no-activity app start guard
Only run the no-activity startup check for unresolved app starts or when
standalone app start tracing registered a listener. This keeps API 35
ApplicationStartInfo classifications from triggering legacy side effects.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* test(android): Opt into standalone no-activity API 35 tests
Register a no-op no-activity listener for API 35 end-time resolution tests
so they exercise the standalone path under the restored legacy guard.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Schedule no-activity idle check when standalone listener is set on API 35+
On API 35+, ApplicationStartInfo resolves appStartType before the
standalone app start listener is installed, causing the idle handler
condition to be false and skipping the no-activity detection entirely.
Register the idle handler from setOnNoActivityStartedListener when the
type is already resolved, ensuring onNoActivityStarted() fires for
standalone app start tracing on API 35+ devices.
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Remove dead foregroundImportance check in standalone app start path
The foregroundImportance guard was always true at that point because
appStartTime is only set to non-null inside the foregroundImportance
branch. Remove the redundant check and the misleading else comment
that described an unreachable code path.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Prevent duplicate standalone app start measurements
Require the app-start pending flag even when standalone app-start transactions bypass foreground checks. Preserve completed non-activity app-start timings so fallback resolution does not overwrite stopped spans.
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Remove unused app start application context
Drop dead AppStartMetrics state that was assigned during lifecycle callback registration but never read.
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Rename getAppStartTimeSpanDirect to getAppStartTimeSpanForStandalone
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Do not set TTID/TTFD contributing flags on standalone app start spans
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Add volatile to noActivityStartedListener for cross-thread visibility
The field is written by setOnNoActivityStartedListener (called during
Sentry.init(), potentially on a background thread) and read on the main
thread in handleNoActivityStartIfNeededOnMain. Without volatile, the JMM
permits the main thread to see a stale null, silently skipping the
listener and preventing standalone app-start transaction creation.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Clear stale app start sampling decision in non-activity start path
onNoActivityStarted() did not clear the appStartSamplingDecision, which
could leak to the first ui.load transaction when an activity eventually
starts after a non-activity process launch.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix: Format adb test commands in TestBroadcastReceiver JavaDoc
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Rename headless app start handling
Use headless terminology for app starts that do not reach an Activity and
schedule the headless check from lifecycle callback registration. This removes
listener setter side effects while preserving standalone app-start behavior.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Align foreground app start measurements
Use the foreground app start fallback for foreground standalone app
start transactions so measurements match the transaction timestamp.
Keep the headless-only span source limited to true headless starts.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Gate headless app start end time
Resolve the headless app start end timestamp only when standalone
headless tracing is active. This avoids stopping legacy app start
spans before a later foreground Activity can finish them.
Co-authored-by: Cursor <cursoragent@cursor.com>
* test(android): Update API 35 headless app start expectation
Make the ApplicationStartInfo headless test install the listener that
now gates headless end-time resolution, matching the standalone path.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Fix headless app-start idle scheduling
* ref(android): Clarify headless app start state names
Rename private headless app start flags to distinguish the pending
main-thread check from the one-shot listener invocation guard. No
behavior change.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): Use app.start origin for headless app start transaction
Set the standalone headless app start transaction origin to
`auto.app.start` instead of `auto.ui.activity`, which was semantically
incorrect for non-activity (broadcast/service/content provider) starts.
Also simplify the API 35+ ApplicationStartInfo onCreate timestamp
resolution by using the reported nanos directly as the uptime base.
Co-authored-by: Cursor <cursoragent@cursor.com>
* ref(android): refine standalone app start trace continuation
Drop the redundant trace-id sharing TransactionContext constructor; the
ui.load now shares the app.start trace solely through continueTrace.
Don't connect a headless app.start and a following activity's ui.load into
the same trace when they are more than 1 minute apart, since such a large
gap means they no longer belong to the same launch.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): align headless app start tests with uptime-based onCreate timestamp
ApplicationStartInfo's START_TIMESTAMP_APPLICATION_ONCREATE is captured via
SystemClock.uptimeNanos(), the same base as TimeSpan, so no clock re-anchoring
is needed. Add the missing headless test setup (foreground-importance stubbing)
and fix the API 35 timestamp test to use uptime semantics.
Co-authored-by: Cursor <cursoragent@cursor.com>
* test(android): add standalone app start E2E harness
Wire the Android sample app for manual standalone app-start validation and add a reusable harness plus notes for the scenarios verified locally. Trim redundant comments around app-start trace continuation while keeping the non-obvious sampling and parentage details.
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* chore(android): remove standalone app start report
Co-authored-by: Cursor <cursoragent@cursor.com>
* test(android): clarify app start transaction shapes
Co-authored-by: Cursor <cursoragent@cursor.com>
* chore(android): remove standalone app start harness
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Preserve app start activity counter
Keep the foreground headless guard from faking an observed activity so
late standalone app start init still lets the first real activity classify
startup and reset warm-start state correctly.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(android): Finish app start after activity spans
Keep standalone app-start transactions open until activity lifecycle spans
are attached so early app-start completion does not drop activity spans.
Co-Authored-By: Cursor <cursoragent@cursor.com>
* feat(samples): enable standalone app start tracing and add headless-start broadcast receiver
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(changelog): resolve merge conflict and keep standalone app start entry under Unreleased
Co-authored-by: Cursor <cursoragent@cursor.com>
* docs(options): Clarify standalone app start javadoc per review
- Use plain quotes for the "App Start" transaction name instead of {@code}
- Clarify that the API 35 gate refers to the device's runtime OS version
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(android): Clarify ApplicationStartInfo onCreate timestamp marks onCreate start
START_TIMESTAMP_APPLICATION_ONCREATE is captured right before
Application.onCreate is invoked (ActivityThread.handleBindApplication),
so it is the onCreate start, not its end. Rename locals, fix comments
and javadoc accordingly, and drop the applicationOnCreate.setStoppedAt
branch which could have recorded a zero-length application.load span.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
📜 Description
Adds standalone Android app-start transaction support behind the opt-in
enableStandaloneAppStartTracingoption and theio.sentry.standalone-app-start-tracing.enablemanifest key.This PR also covers the non-activity startup path so cold starts triggered by broadcasts or foreground services can emit an
App Start Cold/Warmtransaction without waiting for an activity. The legacy flag-off behavior is preserved: activity app-start data remains nested under theui.loadtransaction.Additionally this PR adds a new attribute:
app.vitals.start.screen💡 Motivation and Context
Resolves: #5046
Standalone app-start traces make app-start performance visible independently from activity load transactions, and they let Android report app starts where no activity is launched. The implementation keeps the default behavior unchanged and adds tests for the new option, manifest metadata, transaction context trace reuse, app-start metrics, event processing, and activity lifecycle behavior.
App-start creation paths
This PR preserves the existing flag-off behavior and adds a separate standalone app-start branch when
enableStandaloneAppStartTracingis enabled.ActivityLifecycleIntegrationstarts a standaloneApp Starttransaction and the normal activityui.loadtransaction on the same trace.app.startfor app-start phases, andui.loadfor TTID/TTFD. Theui.loadtransaction does not contain anapp.start.cold/warmchild.ui.loadtransaction with nestedapp.start.cold/warm, plus app-start phase spans under that child.Application.onCreatestart/end throughAppStartMetrics.onApplicationCreate/PostCreate. When no activity starts,ActivityLifecycleIntegrationemits from that completed app-start span.App Starttransaction and noui.load; includesprocess.loadandapplication.loadphase spans.AppStartMetricsreadsApplicationStartInfofromActivityManagerto determine start type and use the platformAPPLICATION_ONCREATEtimestamp as the app-start end time.App Starttransaction and noui.load; includesprocess.load, but notapplication.loadbecause the SDK does not have plugin instrumentation for that phase.ApplicationStartInfois unavailable, soAppStartMetricsdefaults the no-activity process start to cold and uses the class-loaded timestamp fallback for the app-start end time.App Starttransaction and noui.load; includesprocess.loadonly and remains classified as cold.App Starttransaction stores its trace ID for a later activity.ui.loadreuses the stored trace ID and does not create a second standalone app-start transaction.💚 How did you test it?
./gradlew spotlessApply apiDumpscripts/test-standalone-app-start.sh, summarized below.End-to-end Sentry verification
App Startemits alongside siblingMainActivity ui.load; shared trace ID;ui.loadhas noapp.start.*child.app.start(app_start_cold=1156ms) +activity.loadx2 +process.load+application.load; siblingui.load(time_to_initial_display=1156ms)52154e91...ui.loadwithapp.start.coldnested inside.ui.load(time_to_initial_display=1536ms) -> nestedapp.start.cold(app_start_cold=1537ms) ->process.load+activity.loadx2d3f0e049...app.start(app_start_cold=1408ms) +process.load+application.load; noui.load81ae80f6...ApplicationStartInfo.app.start(app_start_cold=525ms) +process.loadonly; noui.load0dcd120e...CLASS_LOADED_UPTIME_MS.app.start(app_start_cold=614ms) +process.loadonly; correctly classified Coldac8a9189...app.start(app_start_cold=4605ms) +process.load+application.load; noui.load905262ce...app.start(app_start_cold=1751ms) + later siblingui.load(time_to_initial_display=4563ms); no duplicate standalone5da4a88f...📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps