| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Sorry, something went wrong.
📲 Install BuildsAndroid
|
Sorry, something went wrong.
Performance metrics 🚀
Baseline results on branch: mainStartup times
App size
Previous results on branch: feat/android-app-start-reasonStartup times
App size
|
Sorry, something went wrong.
There was a problem hiding this comment.
Adds Android 15+ (API 35) enrichment to standalone app start tracing by attaching a stable, low-cardinality process start “reason” derived from ApplicationStartInfo.getReason() as trace data on the standalone app.start transaction.
Changes:
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file| File | Description |
|---|---|
| sentry-android-core/src/main/java/io/sentry/android/core/performance/AppStartMetrics.java | Adds getAppStartReason() mapping logic and a test-only setter for cached ApplicationStartInfo. |
| sentry-android-core/src/main/java/io/sentry/android/core/ActivityLifecycleIntegration.java | Writes app.start.reason trace data onto standalone app.start transactions in both foreground and headless flows. |
| sentry-android-core/src/test/java/io/sentry/android/core/performance/AppStartMetricsTestApi35.kt | Adds API 35 tests for reason→string mapping and null cases. |
| sentry-android-core/src/test/java/io/sentry/android/core/ActivityLifecycleIntegrationTest.kt | Adds tests asserting app.start.reason is present/absent on standalone transactions (foreground and headless). |
| sentry-android-core/api/sentry-android-core.api | Updates API dump for the new AppStartMetrics methods. |
| CHANGELOG.md | Documents the new app.start.reason data on API 35+ for standalone app start transactions. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Sorry, something went wrong.
…ction Read ApplicationStartInfo.getReason() (API 35+) and attach it as app.start.reason trace data on the standalone app.start transaction in both the foreground and headless paths. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Advertise that standalone app start tracing is active by adding a StandaloneAppStart marker to the SDK metadata integrations when the feature is enabled. Internal SDK metadata only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Looks great! I feel a bit mixed about the added ActivityLifecycleIntegrationTest.kt since we're just setting the value and then getting it.
Sorry, something went wrong.
There was a problem hiding this comment.
dope!
Sorry, something went wrong.
Ah yeah, the mapping itself is covered in AppStartMetricsTestApi35, so these activity integration tests are really just checking the wiring that the reason ends up on the standalone app.start transaction under the right key, for both the foreground and headless paths |
Sorry, something went wrong.
Address review feedback to mention that customers can search and group by the app.vitals.start.reason attribute. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
📜 Description
Reports why the OS started the process on the standalone app start transaction, using ApplicationStartInfo.getReason() (Android 15 / API 35+).
Only standalone app start transactions are affected; this rides the existing enableStandaloneAppStartTracing opt-in and adds no new option.
💡 Motivation and Context
Builds on standalone app start tracing (#5342). The reason is a high-value dimension for standalone starts: it distinguishes a real user launch (launcher / start_activity) from headless starts (broadcast, service, content_provider, job, …) — exactly the disambiguation the headless app start path was built for. The reason (why the process started) is orthogonal to cold/warm (getStartType()), so both are reported.
ApplicationStartInfo is already cached in AppStartMetrics from the standalone work, so this only reads one additional field (getReason()) off the same object — no extra system calls.
💚 How did you test it?
Unit tests in sentry-android-core:
Note: the headless-vs-foreground detection in PerformanceAndroidEventProcessor keys off the absence of app.vitals.start.screen; the new distinct app.vitals.start.reason key does not affect it (existing tests still pass).
📝 Checklist
🔮 Next steps