[runningcode]

📜 Description

Moves the ANR integrations to use the MonotonicTicker abstraction. This also makes them more testable since we aren't hard coding a direct access to SystemClock.

A note: We previously used SystemClock.uptimeMillis which does not include time spent in sleep. The implementation of MonotonicTicker on Android uses SystemClock.elapsedRealtimeNanos(). ANRWatchDog polls in the background too, so right after the device wakes up the deadline can already have passed. That doesn't produce a false ANR: the watchdog only reports when ActivityManager also lists the process as NOT_RESPONDING. The cost is one extra getProcessesInErrorState() call after a wake-up. AnrProfilingIntegration only polls in the foreground and resets its reading on foreground.

Also ANRWatchdog was previously using a ICurrentDateProvider. Which has two different implementations, a wall clock and a monotonic clock. It happens to work by chance on Android because on Android it should always return a monotonic clock but this is quite brittle.

💡 Motivation and Context

Fixing clocks and making the code more sane.

• resolves: JAVA-579

💚 How did you test it?

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

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

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

[runningcode]

This returns EITHER a monotonic clock or a wall clock depending on the platform. This is a bad abstraction.
On android it gives you a monotonic clock which is what we want for this class, but the fact that it has Date in the name but gives you a monotonic clock is quite confusing.

[cursor]

Stale Bugbot comment from a previous run.

[runningcode]

This is probably the only weird design about this PR. Open to other ways of doing this!

[markushi]

I see two other options, none of them is great:

1. Open up the SentryOptions with a setMonotonicTicker
2. Static mocks within the tests

val testTicker = TestMonotonicTicker(0)
fun withMockedTicker(closure: () -> Unit) {
  Mockito.mockStatic(AndroidMonotonicTicker::class.java).use { mock ->
    mock
      .`when`<Any> { AndroidMonotonicTicker.getInstance() }
      .thenReturn(testTicker)
    closure()
  }
}

(In the long run replacing the generic SentryOptions with a custom interface , e.g. AnrProfilingIntegrationOptions in this case feels like the right solution).

[runningcode]

I agree that having a custom interface is the way to go, but I don't want to blow up the scope of this PR.
For now I'll use static mocks in tests since that avoids adding an extra API.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 4a11cb6. Configure here.}

[cursor]

Sleep inflates ANR profiling stalls

Medium Severity

Measuring the stall with elapsedRealtime counts time the device spent asleep. ProcessLifecycleOwner keeps the app started for 700ms of uptime after the screen turns off, so a suspend in that window makes checkMainThread treat the sleep as a main-thread stall and persist a false ANR profile.

 

^{Reviewed by Cursor Bugbot for commit 4a11cb6. Configure here.}

[markushi]

That's fine for now, we only ever report the profile if there's an ANR available via ApplicationExitInfo APIs.