ref(android): Measure ANR thresholds on the uptime clock (JAVA-579)

[runningcode]

PR Stack (Clock semantics hardening)

• feat(time): Add uptime and elapsed-real-time clock abstractions (JAVA-571) #6028
• feat(time): Add Timestamp, Timing and EpochClock (JAVA-572) #6045
• fix(android): Treat an unpopulated connection cache as stale (JAVA-717) #6029
• ref(transport): Measure rate-limit backoff on a monotonic clock (JAVA-574) #6030
• ref(checkin): Measure check-in durations with Stopwatch (JAVA-576) #6032
• this PR
• ref(time): Deprecate the legacy date and clock providers (JAVA-571) #6043

---

📜 Description

Moves both ANR detectors off SystemClock.uptimeMillis() readings behind an untyped
ICurrentDateProvider and onto the UptimeClock interface from #6028.

• ANRWatchDog takes an UptimeClock instead of an ICurrentDateProvider lambda, and tracks the
  main thread's responsiveness window as a Deadline rather than a lastKnownActiveUiTimestampMs
  long plus subtraction.
• AnrProfilingIntegration reads its suspicion and ANR thresholds from an injected UptimeClock
  instead of calling SystemClock inline, and times stack capture with a Stopwatch.
• TestTicker's tick is now @Volatile, because these tests advance the clock from the test thread
  while the watchdog thread reads it.

JavaUptimeClock is System.nanoTime(), which is CLOCK_MONOTONIC on Android — the same clock
behind SystemClock.uptimeMillis(). The thresholds are therefore unchanged; only the precision of
the reading and the name on the type change. Nothing serialized is touched.

💡 Motivation and Context

ANR detection is the one place in the SDK where picking the wrong clock invents user-visible events.
uptimeMillis() excludes deep sleep, which is exactly "time the CPU was available to the main
thread". On an elapsed-real-time clock, a 30 s suspend between posting the ticker and checking it
would look like a 30 s frozen UI and report an ANR that never happened. The old
ICurrentDateProvider field type could not tell those two clocks apart; UptimeClock cannot be
handed the wrong one without failing to compile.

This is also what gives UptimeClock a permanent consumer rather than only the behaviour-freeze one
in #6032.

• resolves: JAVA-579

💚 How did you test it?

./gradlew :sentry-android-core:testReleaseUnitTest :sentry-android-core:apiCheck — green.

New regression test a device suspend does not trip the ANR threshold: the watchdog polls for
hundreds of milliseconds of wall time while the uptime clock stands still, and no ANR is reported.
That is precisely the event an elapsed-real-time clock would fabricate. Its counterpart, the
existing when ANR is detected test, advances the same clock and does report one.

The AnrProfilingIntegration state-machine tests now drive the injected clock instead of
Robolectric's shadow SystemClock, asserting the same IDLE → SUSPICIOUS → ANR_DETECTED transitions
at the same offsets.

📝 Checklist

• I added GH Issue ID & Linear ID
• 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.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

PR 6 of the stack deprecates the legacy ICurrentDateProvider family and the date-reading helpers
now that the internal consumers have moved off them.

⚠️ Merge this PR using a merge commit (not squash), so the rest of the stack keeps a clean history.

[linear-code]

JAVA-579

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.54.0 (1)	release

⚙️ sentry-android Build Distribution Settings