Audit finding A1 — design flaw (root cause), HIGH.
ICurrentDateProvider.getCurrentTimeMillis() has two implementations with different clock semantics under the same method name:
CurrentDateProvider → System.currentTimeMillis() (wall/epoch) — sentry/src/main/java/io/sentry/transport/CurrentDateProvider.java:18AndroidCurrentDateProvider → SystemClock.uptimeMillis() (monotonic, pauses in deep sleep) — sentry-android-core/src/main/java/io/sentry/android/core/internal/util/AndroidCurrentDateProvider.java:20
Every consumer must hand-pick the impl matching whatever it compares against (AnrV2/Tombstone use wall vs ApplicationExitInfo.getTimestamp(); LifecycleWatcher uses wall vs Session.getStarted(); AndroidEnvelopeCache uses uptime vs TimeSpan.getStartUptimeMs(); ANRWatchDog bypasses both with an inline uptime lambda). Nothing enforces the correct pairing: a wrong wiring compiles, is silent (tests inject fakes), and is catastrophic — e.g. uptime fed into Timer.schedule(task, absoluteDate) yields a 1970 date that fires instantly.
Every current pairing happens to be correct today, but only via careful manual wiring. This is the root hazard behind several of the other issues in this project.
Source: JAVA-557 §A1.
Audit finding A1 — design flaw (root cause), HIGH.
ICurrentDateProvider.getCurrentTimeMillis()has two implementations with different clock semantics under the same method name:CurrentDateProvider→System.currentTimeMillis()(wall/epoch) —sentry/src/main/java/io/sentry/transport/CurrentDateProvider.java:18AndroidCurrentDateProvider→SystemClock.uptimeMillis()(monotonic, pauses in deep sleep) —sentry-android-core/src/main/java/io/sentry/android/core/internal/util/AndroidCurrentDateProvider.java:20Every consumer must hand-pick the impl matching whatever it compares against (AnrV2/Tombstone use wall vs
ApplicationExitInfo.getTimestamp(); LifecycleWatcher uses wall vsSession.getStarted(); AndroidEnvelopeCache uses uptime vsTimeSpan.getStartUptimeMs(); ANRWatchDog bypasses both with an inline uptime lambda). Nothing enforces the correct pairing: a wrong wiring compiles, is silent (tests inject fakes), and is catastrophic — e.g. uptime fed intoTimer.schedule(task, absoluteDate)yields a 1970 date that fires instantly.Every current pairing happens to be correct today, but only via careful manual wiring. This is the root hazard behind several of the other issues in this project.
Source: JAVA-557 §A1.