Repository navigation
ref(android)!: Mark sentry-android-core classes final - #6494
Merged
Merged
Conversation
4 of 9 tasks
📲 Install BuildsAndroid
|
runningcode
added
the
sanity-check
runningcode
marked this pull request as ready for review
November 10, 2026 07:15
runningcode
requested review from
markushi and
romtsn
and removed request for
a team
November 10, 2026 07:15
romtsn
approved these changes
Nov 10, 2026
romtsn
left a comment
romtsn
left a comment
Contributor
There was a problem hiding this comment.
verified with clanker that none of these classes are being inherited across public github repos and our hybrid SDKs 🎉
Error Prone's Nopen check requires every class to be final, abstract or @OPEN. It never ran on sentry-android-core, so 42 classes were left open. None of them is subclassed except ActivityLifecycleCallbacksAdapter, which becomes abstract since it is only extended, never instantiated. The protected members of the classes that are now final become package-private, as nothing can subclass them anymore. BREAKING CHANGE: AnrV2Integration, AnrProfilingIntegration, SentryUserFeedbackForm and its Builder, WindowContentChangedCallback and several internal classes can no longer be subclassed. ActivityLifecycleCallbacksAdapter can no longer be instantiated directly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…APIs On main, the deprecated SentryUserFeedbackDialog and its Builder still extend SentryUserFeedbackForm and its Builder, so those two stay @OPEN until the dialog is removed. The deprecated SentryUserFeedbackButton and SentryUserFeedbackDialog.Builder become final. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
runningcode
force-pushed
the
no/android-core-nopen
branch
from
November 10, 2026 13:16
dd61e10 to
53dde72
Compare
runningcode
enabled auto-merge (squash)
November 10, 2026 13:22
3 tasks done
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
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
We weren't running no-open on
sentry-android-core. In order to re-enable it we need to declare classes final. Technically this is a breaking API change so feel free to push back and say this should go on v9.My goal is to re-enable no-open and error-prone.
The public classes outside
internalpackages that can no longer be subclassed are:AnrV2IntegrationAnrProfilingIntegrationSentryUserFeedbackButtonandSentryUserFeedbackDialog.BuilderWindowContentChangedCallbackThe other classes are
@ApiStatus.Internalor in aninternalpackage.SentryUserFeedbackFormand itsBuilderstay open, marked@Open, because the deprecatedSentryUserFeedbackDialogand itsBuilderextend them until the dialog is removed.💡 Motivation and Context
💚 How did you test it?
Compiled with Error Prone enabled: no Nopen findings remain and none are added. The
sentry-android-coreunit tests pass.📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
Some of the internal classes are used by hybrid SDKs, for example
AppStartMetrics,ScreenshotUtilsandCurrentActivityHolder. Calling them is unaffected. Subclassing them, or mocking them with a subclass-based mock maker, no longer works.Issues
🤖 Generated with Claude Code