getsentry / getsentry/sentry-java

Incorrect app start transaction duration when app goes in sleep

Aberta
#5,752 1 comentário 0 reações 1 responsável Reivindicada por @runningcode Ver no GitHub
Android Bug Platform: Android Platform: Java
Linguagem predominante
Kotlin
Estrelas
1.4k
Forks
478
Merge médio
2d 22h
PRs com merge (30d)
69

Descrição

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

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.