ref(android): Deprecate AndroidCurrentDateProvider (JAVA-728) - #6103
Open
runningcode wants to merge 6 commits into
Open
ref(android): Deprecate AndroidCurrentDateProvider (JAVA-728)#6103runningcode wants to merge 6 commits into
runningcode wants to merge 6 commits into
Conversation
AndroidCurrentDateProvider.getCurrentTimeMillis() is SystemClock.uptimeMillis(): not a date, and not a clock that counts deep sleep. Neither the name nor the ICurrentDateProvider type says so, and CurrentDateProvider implements that same interface with epoch milliseconds, so a call site declaring the interface accepts either and the two disagree by however long the device has been suspended. MonotonicTicker names the guarantee it gives and keeps counting through deep sleep. The annotation goes on getInstance() rather than on the type. The Android modules compile at Java 8, where javac still warns on an import of a deprecated type, and an import declaration cannot carry a @SuppressWarnings. Deprecating the sole factory method warns every caller just the same, and each warning lands somewhere a suppression can go. Nothing is migrated and nothing is removed. The five suppressed call sites are the migration list. AndroidEnvelopeCache cannot move on its own: it subtracts TimeSpan.getStartUptimeMs(), which is SystemClock.uptimeMillis() too, so moving one operand alone would subtract two different clock bases. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
📲 Install BuildsAndroid
|
…VA-728) Deprecating the type rather than getInstance() says the hazard is the class itself, and warns on every mention of it, the import included. That is only affordable because this class has five use sites. An import of a deprecated type still warns at Java 8 (JEP 211 elides those only from source 9 on), -Werror turns it into an error, and an import declaration cannot carry a @SuppressWarnings. Dropping the five imports for fully-qualified names puts every reference inside a declaration that a suppression can cover. Verified by re-adding one import: the build fails with "warning: [deprecation] AndroidCurrentDateProvider in io.sentry.android.core.internal.util has been deprecated". The suppression comments now point at JAVA-729, which tracks migrating the call sites, rather than restating the reasoning at each one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deprecating the type required replacing all five imports with fully qualified names, since an import of a deprecated type warns at Java 8 and an import cannot carry a @SuppressWarnings. That churn bought nothing. The constructor is private, so getInstance() is the only way into this class and deprecating it warns every real caller identically. Type-level deprecation would only add a warning for declaring a variable of the concrete type, which nothing does: every holder declares ICurrentDateProvider. Measured the alternatives before reverting. Neither a class-level @SuppressWarnings nor a static import silences the import warning; only a fully qualified name, or a reference from inside the type's own package, avoids it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
runningcode
marked this pull request as ready for review
September 11, 2026 15:54
runningcode
requested review from
0xadam-brown,
adinauer,
markushi and
romtsn
as code owners
September 11, 2026 15:54
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📜 Description
Deprecates
AndroidCurrentDateProvider.getInstance()in favor ofio.sentry.time.MonotonicTicker, and documents the replacement in the type's javadoc.JAVA-729 tracks the removal.
Why the annotation is on
getInstance()and not on the typeWe can't add a
SuppressWarningson the imports so I just added it ongetInstancesince it is the only way in to the class.Verification
well, it compiles
💡 Motivation and Context
It is super confusing.
ICurrentDateProviderhas two implementation, one which returnsSystem.currentTimeMillis- a wall clock - and this one which returnsSystemClock.uptimeMillis()- a monotonic clock.💚 How did you test it?
See "Verification" above.
📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
JAVA-729 migrates the five call sites off the deprecated provider. The
Debouncersites are a behavior change (the debounce interval starts counting deep sleep), andAndroidEnvelopeCacheis coupled toTimeSpan's uptime base, so it cannot move alone.🤖 Generated with Claude Code