ref(checkin): Measure check-in durations with Stopwatch (JAVA-576)

[runningcode]

PR Stack (Clock semantics hardening)

• feat(time): Add a monotonic clock abstraction (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
• this PR
• ref(android): Measure ANR thresholds on the monotonic clock (JAVA-579) #6041
• ref(time): Deprecate the legacy date and clock providers (JAVA-571) #6043

---

📜 Description

All four check-in paths kept a start tick and subtracted it in a finally:

// before
final long startTime = System.nanoTime();
...
checkIn.setDuration(DateUtils.nanosToSeconds(System.nanoTime() - startTime));

// after
final @NotNull Stopwatch stopwatch = Stopwatch.started(scopes.getOptions().getMonotonicClock());
...
checkIn.setDuration(DateUtils.nanosToSeconds(stopwatch.elapsedNanos()));

CheckInUtils plus SentryCheckInAdvice in sentry-spring, sentry-spring-jakarta and sentry-spring-7.

Stacked on #6030 → #6029 → #6028.

💡 Motivation and Context

A check-in duration is meant to say how long the job took, which is what a cron monitor's alerting thresholds are set against. Reading the clock from the options gives that meaning on both platforms:

• JVM: unchanged, to the bit. MonotonicClock there is System.nanoTime(), the same reading the code took before. This is the same arithmetic behind a name.
• Android: deep sleep now counts. MonotonicClock is SystemClock.elapsedRealtimeNanos(), so a job that spans a suspend reports the duration a user would measure rather than the time the CPU happened to be awake.

The Android half is a change to a serialized value, which the rest of this series holds for v9 — so it is called out under Behavioral Changes in the changelog rather than slipped in. It is the correct value for the field, the affected surface is cron check-ins on Android, and deferring it would mean shipping the wrong number for another major just to keep the diff inert.

An uninitialised SDK still reaches a clock: NoOpScopes.getOptions() returns empty options, whose clock is the JVM one.

• resolves: JAVA-576

💚 How did you test it?

No new tests. The conversion is mechanical and the existing check-in tests already assert the emitted duration; a test that Stopwatch.started(...) measures elapsed time would be testing StopwatchTest a second time. One existing CheckInUtilsTest case needed scopes.options stubbed, now that the clock is read from there.

.api has no diff. sentry's check-in tests pass, and all four modules compile.

A pre-existing failure you should know about, since it is in the files this PR touches: SentryCheckInAdviceTest fails locally for me in all three Spring modules — 14 failures, expected:<1> but was:<0> on the captureCheckIn verifications. I confirmed it is not caused by this change by running the same tests on a clean origin/main worktree: the same failures, with none of this stack applied. It looks like a local environment problem rather than a repo one, but I could not rule that out from here, so CI on this PR is the real check.

📝 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.

[linear-code]

JAVA-576

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings