Empty OpenBubbles group-summary notification leaks into notification list as `com.openbubbles.messaging` (parked ob-notification-filter regressed out of mainline)

[jameswagar]

Summary

On every incoming iMessage, a second, empty notification appears in the launcher's notification list rendered as com.openbubbles.messaging (the raw package name), alongside the real message. It's OpenBubbles' group-summary notification, which DumbNotificationListenerService surfaces because it isn't filtered out on mainline. A filter for this exact case already exists on a parked branch but was reverted out of main.

Environment

• Device: TCL Flip (Gflip6_USCC), Android 11
• Launcher: v5.5.0 (189); listener unchanged since 2d81da52 (2026-06-02), so v5.6.0/v5.7.0 (190/191) are affected identically
• OpenBubbles: com.openbubbles.messaging 20002233

Repro

1. Receive any iMessage while OpenBubbles is the backend.
2. Observe two notifications in the launcher list: the real one (sender/body) and an empty one titled com.openbubbles.messaging.

Root cause

OpenBubbles posts an explicit per-conversation group summary with no title/text (CreateIncomingMessageNotification.kt: setGroupSummary(true), GROUP_ALERT_CHILDREN, no setContentTitle). Captured live:

pkg=com.openbubbles.messaging  id=0  tag=…NEW_MESSAGE_NOTIFICATION
channel=com.bluebubbles.new_messages.<guid>
flags=0x210  (FLAG_GROUP_SUMMARY | FLAG_AUTO_CANCEL)
android.title=null  android.text=null

A normal Android shade collapses summaries under their children, but the launcher's flat list shows every posted notification. DumbNotificationListenerService.toItem() falls back to the package name when the title is blank:

title = if (title.isBlank()) packageName else title   // line ~145

→ renders as com.openbubbles.messaging. It can't be channel-blocked because the summary shares its channel (com.bluebubbles.new_messages.<guid>) with the real messages.

This already has a written fix that was parked

Branch feature/cover-display-loading-and-ob-notification-filter contains the filter in DumbNotificationListenerService — and its own comment cites this exact notification (NEW_MESSAGE_NOTIFICATION id=0 with flags=0x210):

if (flags and Notification.FLAG_GROUP_SUMMARY != 0) return "FLAG_GROUP_SUMMARY"
if (flags and 0x400 != 0) return "FLAG_AUTOGROUP_SUMMARY"        // FLAG_AUTOGROUP_SUMMARY
…
if (title.isEmpty() && text.isEmpty() && bigText.isEmpty()) return "blank-title-and-text"

It was reverted out of main in bf066ae0 (2026-05-11, "OB notification work parked … for later deploy").

Possible regression (unconfirmed)

A single reporter (me) did not notice this empty summary on the device when it was first received, and it became apparent later. The cause of that change is unconfirmed, and the timeline does not obviously support a launcher regression: the filter was parked out of main on 2026-05-11 — before this device was provisioned (2026-06-01) — and the listener has been unchanged since 2026-06-02. So it may not be a regression at all. Equally plausible: the summary is silent and auto-cancelling and simply went unnoticed at first, the relevant per-conversation channel had not yet been created, or the originally-shipped OpenBubbles build behaved differently. Flagging as a possible regression, not a confirmed one — the core report (the unfiltered summary) stands regardless of cause.

Suggested fix

Redeploy the FLAG_GROUP_SUMMARY / FLAG_AUTOGROUP_SUMMARY guard from the parked branch into main's onNotificationPosted filter path.

Severity

Cosmetic — the summary is silent (GROUP_ALERT_CHILDREN) and auto-cancels — but it duplicates a notification on every incoming message, which is conspicuous on a minimalist flat list.

[jameswagar]

Heads-up: a blanket FLAG_GROUP_SUMMARY drop breaks missed-call notifications

While testing a runtime version of this filter I hit a regression worth flagging before the parked ob-notification-filter ships, because the parked code drops summaries unconditionally:

if (flags and Notification.FLAG_GROUP_SUMMARY != 0) return "FLAG_GROUP_SUMMARY"

The AOSP dialer posts a single missed call as a group summary, so that rule eats it. Captured live:

pkg=com.android.dialer  tag=MissedCall_GroupSummary  channel=phone_missed_call
flags=0x219  (FLAG_GROUP_SUMMARY | AUTO_CANCEL | ONLY_ALERT_ONCE | SHOW_LIGHTS)
groupKey=…g:MissedCall   title="Missed call"   text="<number>"

It has FLAG_GROUP_SUMMARY set but no child in its group — it is the content. A blanket drop removes it from the flat list while the system status bar still shows it (so it looks like "missed calls sometimes appear only in the status bar").

Suggested: make the filter group-aware — only drop a summary when a non-summary notification shares its groupKey. Redundant messaging summaries (OpenBubbles/Telegram, where a child exists) still get dropped; standalone summaries (missed calls, and any single-item group) are kept. Concretely: build the set of groupKeys that contain a non-summary notification, then drop a summary only if its groupKey is in that set.

Verified this distinction resolves both the duplicate-messaging case and the missed-call case.