Skip to content

Fix crash when declining a call with a quick response#194

Merged
thestinger merged 1 commit into
GrapheneOS:mainfrom
thomasbuilds:fix/respond-via-message-npe
Jul 13, 2026
Merged

Fix crash when declining a call with a quick response#194
thestinger merged 1 commit into
GrapheneOS:mainfrom
thomasbuilds:fix/respond-via-message-npe

Conversation

@thomasbuilds

Copy link
Copy Markdown
Contributor

Commit 9aec6f6 replaced the argument-less notification refresh with BugleNotifications.updateWithInlineReply(conversationId, message), which is also reached from the recipients-only RESPOND_VIA_MESSAGE path where conversationId is null. Telecom invokes this exported service whenever the user rejects an incoming call with a quick-response text, and the null conversationId crashes on the non-null channelId parameter of NotificationChannelUtil.getActiveNotification. Since the service sets intent redelivery, the crash also redelivers the intent and re-sends the reply, causing duplicate texts alongside the crash loop.

Move the call into the branch where the conversation is known. The notification inline-reply path always supplies a conversation id, so its behavior is unchanged, and the recipients-only path has no active conversation notification to update in the first place.

@RankoR RankoR left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, But please add a regression test (we already have Robolectric in the project - you can use it).

Commit 9aec6f6 replaced the argument-less notification refresh with
BugleNotifications.updateWithInlineReply(conversationId, message), which
is also reached from the recipients-only RESPOND_VIA_MESSAGE path where
conversationId is null. Telecom invokes this exported service whenever
the user rejects an incoming call with a quick-response text, and the
null conversationId crashes on the non-null channelId parameter of
NotificationChannelUtil.getActiveNotification. Since the service sets
intent redelivery, the crash also redelivers the intent and re-sends
the reply, causing duplicate texts alongside the crash loop.

Move the call into the branch where the conversation is known. The
notification inline-reply path always supplies a conversation id, so
its behavior is unchanged, and the recipients-only path has no active
conversation notification to update in the first place.
@thomasbuilds
thomasbuilds force-pushed the fix/respond-via-message-npe branch from 44b303f to 6506425 Compare July 13, 2026 07:25
@thestinger
thestinger merged commit 02642ca into GrapheneOS:main Jul 13, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants