Conversation
When an interstitial activity (e.g. splash screen) starts the next activity and finishes without ever calling setContentView(), the OnDrawListener never fires and TTID is never reported. This change detects that pattern automatically and forwards the TTID subscription to the next qualifying activity — no customer configuration required.
|
🎯 Code Coverage (details) 🔗 Commit SHA: 095fa1e | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3199 +/- ##
===========================================
+ Coverage 71.26% 71.47% +0.22%
===========================================
Files 929 929
Lines 34457 34489 +32
Branches 5813 5825 +12
===========================================
+ Hits 24553 24651 +98
+ Misses 8263 8210 -53
+ Partials 1641 1628 -13
🚀 New features to boost your workflow:
|
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b94701d6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| val isFirstTrackedActivityWithNoPendingStartup = | ||
| trackedActivities.size == 1 && | ||
| !isChangingConfigurations && | ||
| shouldTrackStartup && | ||
| pendingScenario == null |
There was a problem hiding this comment.
The new pendingScenario == null gate means a startup scenario can block all future startup detection indefinitely if the original interstitial never draws and no follow-up activity is created immediately (for example, user leaves the app after a splash finish(), then returns later in the same process). In that case, the next launch path skips creating a fresh scenario and keeps forwarding the old one, which can suppress the new app-start event and report an inflated TTID based on the stale initialTime.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Not sure how common this case would be.
I see two options here:
-
Prevent stale pendingScenario from blocking future startups by clearing it in
RumAppStartupDetectorImpl.onBeforeActivityCreated()when it’s older thanrumSessionScopeStartupManagerImpl.MAX_TTID_DURATION_NS(let's say 1 minute), so a later “re-launch” in the same process creates a fresh startup scenario instead of forwarding a stale one? -
Accept this case and create some documentation.
Any other ideas?
There was a problem hiding this comment.
Thought about it for a bit. Your option 1 seems like a right thing to do. We already have this 1 minute threshold
for TTID.| val isFirstTrackedActivityWithNoPendingStartup = | ||
| trackedActivities.size == 1 && | ||
| !isChangingConfigurations && | ||
| shouldTrackStartup && | ||
| pendingScenario == null |
There was a problem hiding this comment.
Thought about it for a bit. Your option 1 seems like a right thing to do. We already have this 1 minute threshold
for TTID.
hamorillo
dismissed
aleksandr-gringauz’s stale review
The base branch was changed.
3 participants
What does this PR do?
Note: This PR is targeting hector.morilloprieto/RUM-14471, as it is an iteration of it. It's motivated by this comment.
Automatically detects and forwards TTID (Time To Initial Display) measurement to the next qualifying activity when an interstitial activity (e.g. a splash screen) calls
startActivity()+finish()without ever callingsetContentView(). In this pattern theOnDrawListenernever fires on the interstitial, so TTID is silently dropped. This PR makes the SDK detect that case and subscribe to the next activity's first frame draw instead — with no customer configuration required.Motivation
Customers using a splash/auth screen pattern were losing TTID data entirely because the SDK had no way to recover when the first tracked activity never drew a frame.
How to test
Apply the attached patch to the branch:
The patch modifies the sample app to add a
SplashActivityas the launcher activity. This activity immediately callsstartActivity(NavActivity)+finish()without setting a content view, simulating an interstitial splash screen. It also sets telemetry sampling to 100% and reduces session inactivity timeout to 15 seconds for easier testing.Run the sample app and check the RUM dashboard — you should see TTID reported for
NavActivitywithwas_forwarded: truein the startup telemetry metric.Additional Notes
onBeforeActivityCreatedwhile a pending startup scenario exists).pendingScenario.wasForwardedtelemetry flag added toRumTTIDInfoand reported via the telemetry metric so we can measure how often this path is taken.Review checklist (to be filled by reviewers)