Warm start detection

[stefanosiano]

📜 Description

• ActivityLifecycleIntegration:
  • creates onCreate and onStart TimeSpans
  • set app start type to warm in AppStartMetrics when needed
• AppStartMetrics has now a method to restart appStartSpan and reset its uptime_ms
• PerformanceAndroidEventProcessor now attaches activity start spans to warm starts, too
• SentryPerformanceProvider doesn't create spans anymore

Confirm warm starts are registered for background starts (BroadcastReceiver)

Cold start:

Open second Activity:

Reopen first Activity without closing app:

Open first Activity after close app with Don't keep activity developer option enabled:

💡 Motivation and Context

Fixes #3896
Relates and possibly fixes #3899

💚 How did you test it?

📝 Checklist

• 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

In a followup PR:

• Remove the activityCallback completely from the SentryPerformanceProvider
• Create and attach spans directly in ActivityLifecycleIntegration instead of adding them to AppStartMetrics and let the PerformanceAndroidEventProcessor add them to the transaction
• Avoid creating process init span using setStartUnixTimeMs as it is a testOnly method. This means care, as the method is exposed to hybrid sdks

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	443.22 ms	501.19 ms	57.97 ms
Size	1.70 MiB	2.36 MiB	671.74 KiB

Previous results on branch: fix/warm-starts

Startup times

Revision	Plain	With Sentry	Diff
c21a34f	369.28 ms	441.12 ms	71.84 ms
34c4186	410.50 ms	437.28 ms	26.78 ms

App size

Revision	Plain	With Sentry	Diff
c21a34f	1.70 MiB	2.36 MiB	669.76 KiB
34c4186	1.70 MiB	2.36 MiB	669.76 KiB

[romtsn]

LGTM, but I'm a bit rusty in this part of the codebase already, would love @markushi to take a look

[markushi]

Looking good! Nice job! Since SentryPerformanceProvider doesn't create any spans anymore it's worth mentioning that the app start spans will only be created if the SDK gets initialized before the first activity is launched. Maybe it's worth adding this to our changelog?

[markushi]

Do we still need this check? Since we have a reference to the activity, we could always call irstDrawDoneListener.registerForNextDraw

[stefanosiano]

It's a safety guard: if the window is null (i'm not sure it ever happens), the FirstDrawDoneListener.registerForNextDraw returns early, and the ttid is never stopped.
In this case i just post the ttid finish on the main thread, as it should be good enough

[stefanosiano]

Looking good! Nice job! Since SentryPerformanceProvider doesn't create any spans anymore it's worth mentioning that the app start spans will only be created if the SDK gets initialized before the first activity is launched. Maybe it's worth adding this to our changelog?

i think this was the case before, too, as the cold start span was created by the ActivityLifecycleIntegration anyway, and the SentryPerformanceProvider spans were only added to it.
We guard the app start span creation with the firstActivityCreated flag (that we set to true on create and on pause), so there should be no app start span if the SDK is initialized after the first activity.
Or am i missing a case here?