getsentry / getsentry/sentry-java

Incorrect app start transaction duration when app goes in sleep

未關閉
#5,752 1 則留言 0 個 reaction 已指派 1 人 已被 @runningcode 認領 在 GitHub 檢視
Android Bug Platform: Android Platform: Java
主要語言
Kotlin
星號
1.4k
分支
478
平均合併
2 天 22 小時
30 天內合併 PR
69

描述

As reported by a customer we're seeing the following behavior:

1. App is launched
2. A cold start is detected and an `ui.load` transaction is created (`app.start.cold` + `ttid`)
3. The app is backgrounded before the first frame draws (and the activity only progresses through the `onCreate` + `onStart` phases, no `onDestroy`) — so TTID never happens, and no lifecycle cleanup on our side runs.
4. The device enters Doze, which freezes our deadline timer so it doesn't fire at +30s.
5. Hours later the device wakes up, the deadline finally fires when the app is resumed, and our `forceFinish` stamps the spans with the current time.
6. The resulting transactions spans over multiple hours.

I would argue that we should drop any foreground launches which have a doze in-between, as it just skews the real "user perceived" launches.

On the other hand, a real user was probably waiting for a few seconds for the app to come alive, but it didn't, so the user bailed.

Related issue: getsentry/sentry-java#5530

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。