Skip to content

feat(android): Add standalone app start tracing#5342

Draft
buenaflor wants to merge 25 commits into
mainfrom
feat/standalone-app-start-tracing
Draft

feat(android): Add standalone app start tracing#5342
buenaflor wants to merge 25 commits into
mainfrom
feat/standalone-app-start-tracing

Conversation

@buenaflor
Copy link
Copy Markdown
Contributor

@buenaflor buenaflor commented Apr 28, 2026

📜 Description

Adds standalone Android app-start transaction support behind the opt-in enableStandaloneAppStartTracing option and the io.sentry.standalone-app-start-tracing.enable manifest 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/Warm transaction without waiting for an activity. The legacy flag-off behavior is preserved: activity app-start data remains nested under the ui.load transaction.

Additionally this PR adds two new attributes:

  • app.vitals.start.reason
  • 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 enableStandaloneAppStartTracing is enabled.

Scenario How app start is created Resulting trace shape
Activity launch, flag ON ActivityLifecycleIntegration starts a standalone App Start transaction and the normal activity ui.load transaction on the same trace. Two sibling transactions: app.start for app-start phases, and ui.load for TTID/TTFD. The ui.load transaction does not contain an app.start.cold/warm child.
Activity launch, flag OFF Legacy activity lifecycle tracing creates app start as a child span of the activity transaction. One ui.load transaction with nested app.start.cold/warm, plus app-start phase spans under that child.
Non-activity process start, flag ON, Gradle plugin instrumentation present The Gradle plugin records Application.onCreate start/end through AppStartMetrics.onApplicationCreate/PostCreate. When no activity starts, ActivityLifecycleIntegration emits from that completed app-start span. One standalone App Start transaction and no ui.load; includes process.load and application.load phase spans.
Non-activity process start, flag ON, no Gradle plugin on API 35+ AppStartMetrics reads ApplicationStartInfo from ActivityManager to determine start type and use the platform APPLICATION_ONCREATE timestamp as the app-start end time. One standalone App Start transaction and no ui.load; includes process.load, but not application.load because the SDK does not have plugin instrumentation for that phase.
Non-activity process start, flag ON, no Gradle plugin on API <35 ApplicationStartInfo is unavailable, so AppStartMetrics defaults the no-activity process start to cold and uses the class-loaded timestamp fallback for the app-start end time. One standalone App Start transaction and no ui.load; includes process.load only and remains classified as cold.
Non-activity process start followed by activity The non-activity App Start transaction stores its trace ID for a later activity. The later activity ui.load reuses the stored trace ID and does not create a second standalone app-start transaction.
Non-activity process start, flag OFF The non-activity listener is not installed. Broadcasts/services emit no app-start transaction.

💚 How did you test it?

  • ./gradlew spotlessApply apiDump
  • Targeted unit coverage for the option, manifest metadata, app-start metric resolution, event processing, lifecycle integration, and transaction context trace reuse.
  • Manual end-to-end harness runs from scripts/test-standalone-app-start.sh, summarized below.

End-to-end Sentry verification

# What it tests Locally emitted shape Trace ID link
1a Launcher activity cold start, standalone flag ON. Standalone App Start emits alongside sibling MainActivity ui.load; shared trace ID; ui.load has no app.start.* child. app.start (app_start_cold=1156ms) + activity.load x2 + process.load + application.load; sibling ui.load (time_to_initial_display=1156ms) 52154e91...
1c Launcher activity cold start, standalone flag OFF. Legacy shape preserved: single ui.load with app.start.cold nested inside. ui.load (time_to_initial_display=1536ms) -> nested app.start.cold (app_start_cold=1537ms) -> process.load + activity.load x2 d3f0e049...
2a Broadcast cold, tier-1 end-time resolution with Gradle-plugin timing simulation. app.start (app_start_cold=1408ms) + process.load + application.load; no ui.load 81ae80f6...
2b Broadcast cold, tier-2 end-time resolution via Android 15 ApplicationStartInfo. app.start (app_start_cold=525ms) + process.load only; no ui.load 0dcd120e...
2c Broadcast cold, tier-3 fallback on API 33 using CLASS_LOADED_UPTIME_MS. app.start (app_start_cold=614ms) + process.load only; correctly classified Cold ac8a9189...
2d Foreground service cold start through the non-activity path. app.start (app_start_cold=4605ms) + process.load + application.load; no ui.load 905262ce...
2e Broadcast then launcher: trace reuse without duplicate standalone transaction. Same trace: broadcast app.start (app_start_cold=1751ms) + later sibling ui.load (time_to_initial_display=4563ms); no duplicate standalone 5da4a88f...
2f Broadcast + standalone flag OFF. No transaction emitted --

📝 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

buenaflor and others added 10 commits April 2, 2026 14:43
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>
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>
…entation

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>
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>
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>
…tart-tracing

# Conflicts:
#	sentry-android-core/src/main/java/io/sentry/android/core/performance/AppStartMetrics.java
…icate 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>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 28, 2026

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

Generated by 🚫 dangerJS against cbaebe2

@sentry
Copy link
Copy Markdown

sentry Bot commented Apr 28, 2026

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 28, 2026

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 318.08 ms 367.78 ms 49.70 ms
Size 0 B 0 B 0 B

Baseline results on branch: main

Startup times

Revision Plain With Sentry Diff
674d437 355.28 ms 504.18 ms 148.90 ms
2195398 321.31 ms 391.66 ms 70.35 ms
62b579c 312.88 ms 361.57 ms 48.70 ms
b77456b 393.26 ms 441.10 ms 47.84 ms
694d587 312.37 ms 402.77 ms 90.41 ms
6b019b7 319.84 ms 333.15 ms 13.31 ms
6edfca2 305.52 ms 432.78 ms 127.26 ms
b03edbb 314.90 ms 350.22 ms 35.33 ms
d15471f 294.13 ms 399.49 ms 105.36 ms
fcec2f2 314.96 ms 373.66 ms 58.70 ms

App size

Revision Plain With Sentry Diff
674d437 1.58 MiB 2.10 MiB 530.94 KiB
2195398 0 B 0 B 0 B
62b579c 0 B 0 B 0 B
b77456b 1.58 MiB 2.12 MiB 548.11 KiB
694d587 1.58 MiB 2.19 MiB 620.06 KiB
6b019b7 0 B 0 B 0 B
6edfca2 1.58 MiB 2.13 MiB 559.07 KiB
b03edbb 1.58 MiB 2.13 MiB 557.32 KiB
d15471f 1.58 MiB 2.13 MiB 559.54 KiB
fcec2f2 1.58 MiB 2.12 MiB 551.50 KiB

Previous results on branch: feat/standalone-app-start-tracing

Startup times

Revision Plain With Sentry Diff
8147749 302.52 ms 352.71 ms 50.19 ms
5f2075f 329.13 ms 392.38 ms 63.25 ms
4d58e3f 329.78 ms 405.36 ms 75.58 ms
04a4a5f 319.55 ms 374.56 ms 55.01 ms

App size

Revision Plain With Sentry Diff
8147749 0 B 0 B 0 B
5f2075f 0 B 0 B 0 B
4d58e3f 0 B 0 B 0 B
04a4a5f 0 B 0 B 0 B

buenaflor and others added 2 commits May 4, 2026 10:15
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>
Co-authored-by: Cursor <cursoragent@cursor.com>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 7, 2026

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry-android-core/src/main/java/io/sentry/android/core/InternalSentrySdk.java

@buenaflor
Copy link
Copy Markdown
Contributor Author

@cursor review
@sentry review

Co-authored-by: Cursor <cursoragent@cursor.com>
@buenaflor
Copy link
Copy Markdown
Contributor Author

@cursor review
@sentry review

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 7, 2026

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry-android-core/src/main/java/io/sentry/android/core/InternalSentrySdk.java

@github-actions
Copy link
Copy Markdown
Contributor

🚨 Detected changes in high risk code 🚨

High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:

  • sentry-android-core/src/main/java/io/sentry/android/core/InternalSentrySdk.java

buenaflor and others added 7 commits May 11, 2026 13:00
Co-authored-by: Cursor <cursoragent@cursor.com>
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>
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>
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>
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>
…r 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>
@buenaflor
Copy link
Copy Markdown
Contributor Author

@cursor review

Copy link
Copy Markdown

@cursor cursor Bot left a comment

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 72268a3. Configure here.

finishAppStartSpan();
}
// else: flag ON but not foreground — non-activity launch path is handled
// via the OnNoActivityStartedListener callback.
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Redundant foreground check creates misleading dead-code comment

Low Severity

The && foregroundImportance guard in the standalone branch is unreachable dead code. The enclosing if on line 285 only enters when appStartTime != null, and appStartTime is set to non-null only when foregroundImportance && appStartTimeSpan.hasStarted() (lines 192–198). This makes foregroundImportance always true at that point. As a consequence, the else comment on line 319–320 ("flag ON but not foreground — non-activity launch path is handled via the OnNoActivityStartedListener callback") describes a branch that can never be reached, which can mislead future readers into thinking there is a live code path for background-foreground hand-off within this block.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 72268a3. Configure here.

…p 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>
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.

feat: Send standalone app start transactions

1 participant