What does this PR do?

Extends the fallback guard in DefaultAppStartTimeProvider to also handle the case where the computed appStartTimeNs is greater than DdRumContentProvider.createTimeNs, which is an impossible value since the process always starts before the content provider initialises. Adds a unit test covering this direction, and updates existing uptime tests to set createTimeNs consistently with the production invariant.

Motivation

The CI integration test mustReturnTheCorrectAppStartTime_when_appStartTimeNs failed with a java.lang.AssertionError. The full assertion message was truncated in the CI log, so we cannot confirm the exact values involved, but I think the root cause is a buggy value returned by Process.getStartElapsedRealtime().

This API is known to occasionally return wrong values on API 28+ (confirmed in RUM-13082 and documented in this article). I think that when it returns a value larger than the current elapsedRealtime(), diffMs goes negative and result exceeds System.nanoTime().

The existing guard only caught the case where result was too far in the past:

// Before — only catches one direction
if (DdRumContentProvider.createTimeNs - result > THRESHOLD)

When result > createTimeNs, this expression is negative and the guard silently passes the invalid value through.

Additional context — BOOTTIME vs MONOTONIC clock mismatch

While investigating the failure we also noticed a separate structural issue in the formula:

val diffMs = getDeviceElapsedRealtimeMillis() - Process.getStartElapsedRealtime()
val result  = getDeviceElapsedTimeNanos() - TimeUnit.MILLISECONDS.toNanos(diffMs)

This mixes two different Android clocks:

• getDeviceElapsedRealtimeMillis() → SystemClock.elapsedRealtime() — CLOCK_BOOTTIME, advances during device sleep
• getDeviceElapsedTimeNanos() → System.nanoTime() — CLOCK_MONOTONIC, does not advance during sleep

On a device that sleeps after the process starts, CLOCK_BOOTTIME accumulates more time than CLOCK_MONOTONIC, inflating diffMs and making result too small. Since appStartTimeNs feeds RUM startup duration, TTID, fatal crash timeSinceAppStartNs, and NDK crash timestamps, a wrong value here silently corrupts multiple RUM and crash metrics. This is not addressed by this PR. A proper fix would require Process.getStartUptimeMillis() (available from API 33) to keep the computation in the MONOTONIC domain throughout.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)