Fix RecorderWindowCallback crash on null menu parameter#3239
Conversation
a3dc505 to
f460c15
Compare
This comment has been minimized.
This comment has been minimized.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #3239 +/- ##
===========================================
- Coverage 71.49% 71.38% -0.11%
===========================================
Files 934 934
Lines 34628 34628
Branches 5862 5862
===========================================
- Hits 24755 24718 -37
- Misses 8231 8264 +33
- Partials 1642 1646 +4
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 493ec41725
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| @Suppress("SwallowedException", "UnsafeThirdPartyFunctionCall") // NPE caught below | ||
| override fun onMenuOpened(featureId: Int, menu: Menu): Boolean { |
There was a problem hiding this comment.
Declare menu callback args nullable
These overrides still use non-null parameter types (Menu/MenuItem), so Kotlin emits checkNotNullParameter at method entry and throws before the try/catch can run when the framework passes null. In the null-menu scenario this patch is targeting, onMenuOpened (and the similarly typed onMenuItemSelected, onPanelClosed, onPreparePanel, onCreatePanelMenu) can still crash before delegating.
Useful? React with 👍 / 👎.
bda200b to
c8dd0cb
Compare
| */ | ||
| @RunWith(AndroidJUnit4::class) | ||
| @LargeTest | ||
| internal class AppStartupActivityPredicateTest : |
There was a problem hiding this comment.
I am not sure the change in this file is related to this PR, if not, we need to revert it.
| dependencies { | ||
| api(project(":dd-sdk-android-core")) | ||
| implementation(project(":dd-sdk-android-internal")) | ||
| compileOnly(project(":features:dd-sdk-android-rum")) |
There was a problem hiding this comment.
Note
It's better just to move FixedWindowCallback into dd-sdk-android-internal module (suggested package: "com.datadog.android.internal.utils") instead of letting session replay depend on the whole rum module.
Extend FixedWindowCallback instead of using try-catch overrides, matching the pattern established in PR #2800. Add compileOnly dependency on dd-sdk-android-rum to access FixedWindowCallback.
4e5751e to
3a633c5
Compare
Move FixedWindowCallback from dd-sdk-android-rum to dd-sdk-android-internal (package com.datadog.android.internal.utils) so it can be reused by session-replay without depending on the whole RUM module.
3a633c5 to
442230c
Compare
What does this PR do?
Overrides menu-related
Window.Callbackmethods inRecorderWindowCallbackwith nullable parameters, preventing Kotlin's non-null assertions from crashing when Android passes null values.Motivation
A customer reported a crash (
NullPointerException: Parameter specified as non-null is null: method RecorderWindowCallback.onMenuOpened, parameter p1) when opening a custom popup menu.RecorderWindowCallbackuses Kotlin'sby wrappedCallbackdelegation forWindow.Callback. Kotlin generates non-null assertions for all delegated parameters, but Android can call these methods with null values (known Android bug: https://issuetracker.google.com/issues/188568911). The previous fix only handleddispatchTouchEventwith a try-catch, but the same issue affected all menu-related callbacks.Changes
onMenuOpened,onMenuItemSelected,onPanelClosed,onPreparePanel, andonCreatePanelMenuinRecorderWindowCallbackwith nullable parameters. When null is received, methods return safe defaults (falseor no-op) instead of crashing.dispatchTouchEventtry-catch workaround andlogOrRethrowWrappedCallbackExceptionhelper, sincedispatchTouchEventalready declares its parameter as nullable.Note
This is an alternative to #3221 with a simpler approach: nullable Kotlin overrides instead of a
FixedWindowCallbackJava wrapper class. No new files, no API surface change, no inheritance change.Review checklist (to be filled by reviewers)