Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Clean up the remaining AndroidCurrentDateProvider usages

Ouverte
  • Quelque chose ne va pas ?
#6,104 1 commentaire 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

@runningcode y travaille déjà.

Depuis le 11/9/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

Platform: Java

Follow-up to getsentry/sentry-java#6102, which deprecates AndroidCurrentDateProvider but migrates nothing. Five internal call sites still use it, each carrying a @SuppressWarnings("deprecation") that points here.

Why they should move

AndroidCurrentDateProvider.getCurrentTimeMillis() is SystemClock.uptimeMillis(), which stops advancing while the device is in deep sleep. Any interval measured with it under-reports real elapsed time, so a window looks un-expired long after it actually expired. MonotonicTicker is CLOCK_BOOTTIME via SystemClock.elapsedRealtimeNanos() and keeps counting through deep sleep.

Call sites

Debouncer — internal/util/Debouncer.java reads the provider for its window check. Four constructions pass the uptime provider:

  • ViewHierarchyEventProcessor (2 s window)
  • ScreenshotEventProcessor (2 s window)
  • SystemEventsBreadcrumbsIntegration (60 s window)
  • AppComponentsBreadcrumbsIntegration (60 s window)

The two 60 s breadcrumb debouncers are the ones that can swallow a real breadcrumb: a trim-memory or connectivity event right after a long Doze can land inside a window that expired hours ago in wall time. The 2 s screenshot and view-hierarchy windows are much harder to hit. Note this is a behavior change, not a rename — the debounce interval starts counting deep sleep.

AndroidEnvelopeCache — currentDateProvider.getCurrentTimeMillis() - sdkInitTimeSpan.getStartUptimeMs(), the startup-crash detection threshold. Same deep-sleep skew: a crash long after init, with sleep in between, can fall under startupCrashDurationThresholdMillis and be written as a startup crash.

AndroidEnvelopeCache cannot move in isolation

TimeSpan is documented and implemented on SystemClock.uptimeMillis() (performance/TimeSpan.java:14, :45, :51). Moving only the left operand to a MonotonicTicker tick would subtract two different clock bases — worse than what is there today. Either move TimeSpan's base along with it, or split this call site into its own issue.

Out of scope

  • sentry-android-replay's ICurrentDateProvider consumers — getsentry/sentry-java#5578 / PR #6090.
  • Deleting AndroidCurrentDateProvider. The class is @ApiStatus.Internal and absent from sentry-android-core.api, so removal is not a binary-compat break, but per the project plan removal lands on v9.

Done when

  • No production code references AndroidCurrentDateProvider, or the only remaining reference is AndroidEnvelopeCache with the TimeSpan coupling tracked separately.
  • Every @SuppressWarnings("deprecation") added by getsentry/sentry-java#6102, and its comment, is gone.
  • Tests cover a deep-sleep-style jump: real time advances well past the window while the old uptime source would not have.
Langage dominant
Kotlin
Étoiles
1.4k
Forks
479
Merge moyen
3 j 21 h
PR mergées (30 j)
64

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de getsentry/sentry-java

Toutes les issues de getsentry/sentry-java

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.