Clean up the remaining AndroidCurrentDateProvider usages
维护者通常 2 天内回复
@runningcode 已经在做这个了。
开始于 2026年9月11日。
评估
这个 Issue 还没有评估数据。
描述
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'sICurrentDateProviderconsumers — getsentry/sentry-java#5578 / PR #6090.- Deleting
AndroidCurrentDateProvider. The class is@ApiStatus.Internaland absent fromsentry-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 isAndroidEnvelopeCachewith theTimeSpancoupling 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.
- 主要语言
- Kotlin
- 星标
- 1.4k
- 派生
- 478
- 平均合并
- 3 天 10 小时
- 30 天内合并 PR
- 75
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
getsentry/sentry-java 的其他 Issue
-
Platform: Java
难度 2/5 半天 新手友好度 76/100
getsentry/sentry-java#6161 · 1 条评论 ·
维护者通常 2 天内回复
-
Bug Java Platform: Android Platform: Java
难度 2/5 1-3 小时 新手友好度 78/100
getsentry/sentry-java#6138 · 1 条评论 ·
维护者通常 2 天内回复
-
Feature Java Platform: Java Spans
难度 2/5 1-3 小时 新手友好度 68/100
getsentry/sentry-java#5984 · 1 条评论 ·
维护者通常 2 天内回复
-
Android Task Traces
难度 2/5 1-3 小时 新手友好度 68/100
getsentry/sentry-java#5376 · 1 条评论 ·
维护者通常 2 天内回复
-
Android Docs Errors
难度 2/5 1-3 小时 新手友好度 64/100
getsentry/sentry-java#5375 · 1 条评论 ·
维护者通常 2 天内回复
查看 getsentry/sentry-java 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
-
enhancement
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
SimonHalvdansson/Harmonic-HN#363 ·
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 90/100
Automattic/pocket-casts-android#6095 ·
维护者通常 1 天内回复