You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ae59540
Browse filesBrowse the repository at this point in the historyBrowse files
fix(android): Decide session rotation on a monotonic clock (JAVA-573) (#6096)
* fix(android): Decide session rotation on a monotonic clock (JAVA-573)
Whether foregrounding rotates the session was a comparison between two
System.currentTimeMillis() readings taken up to 30 seconds apart. The gap
between two wall-clock reads is not the time that passed — the device syncs
its clock and the interval comes out too long, too short, or negative — so a
step forward started a session that should have been resumed, and a step back
resumed one that should have ended. Android steps the wall clock most often in
the first seconds after boot, which is exactly where a cold start's background
window lives.
The background window is a duration, so it now lives on a Deadline over
options.getMonotonicTicker(), which on Android is CLOCK_BOOTTIME and so keeps
counting through deep sleep. One deadline serves both halves of the window: the
end-session task is scheduled for its remaining(), and a foreground arriving
first asks whether it hasPassed(). Measuring one window in two places is what
allowed two readings to disagree.
The staleness of a session already on the scope stays on the wall clock and is
now named for it. That path is only reached before the app has been backgrounded
in this process, and the only record of when that session started is
Session.getStarted() — a serialized epoch instant, which no tick can be
compared against. A TODO [MAJOR] marks the real fix: a session that records the
tick it started on.
Passing the clocks in from AppLifecycleIntegration, which already holds the
options being registered, removes the second constructor rather than adding a
third parameter to it.
Two tests were pinning the old behavior: `if last started session is before
interval` stubbed the clock with (2, 1) and passed only because the wall clock
ran backwards. They become a real background-foreground cycle on a
TestMonotonicTicker, with one regression test per step direction.
This leaves the other half of JAVA-573 open: a session that slept through its
window is still stamped when the SDK noticed rather than when the window fell
due, so its duration is inflated by the suspend. That value is serialized, and
#6091 is the template for fixing it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* changelog
* docs(android): Say which lock guards sessionEnd (JAVA-573)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(android): Simplify the wall-clock note on isSessionOnScopeStale (JAVA-573)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(changelog): List the session rotation change as breaking (JAVA-573)
It changes when a new session starts, so session counts shift.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,6 +36,7 @@
36
36
- Manually constructed `SentryTimberIntegration` and `SentryTimberTree` instances require a
37
37
`logsEnabled` argument. Pass `false` to keep Sentry Logs disabled.
38
38
- Remove the Apache HttpClient transport and stop publishing `sentry-apache-http-client-5` ([#6214](https://github.com/getsentry/sentry-java/pull/6214))
39
+
- Decide whether foregrounding the app starts a new session on a monotonic clock instead of the wall clock, so that a device time change no longer starts a session that should have been resumed, or resumes one that should have ended. This affects session counts ([#6096](https://github.com/getsentry/sentry-java/pull/6096))
0 commit comments