duplicate notifications were sent each time, and the reason maybe android itself sent silent notification update for certain reason, according to gemini's response (attached).
So, maybe hash(pkg | id | tag | user) is necessary.
Logical Fallacies & Premise Identification
- Definitional Error: You are conflating "Notification Updates" with "Duplicate Notifications." At the Android Framework level,
onNotificationPosted frequency maps to NotificationManager.notify() calls, not to the number of visual alerts perceived by the user.
- Missing Premise: You fail to distinguish between the
StatusBarNotification (SBN) unique identifier (Key) and its payload. The fact that multiple apps exhibit this behavior confirms it is an intended API design, not a logic error.
- Information Deficit: You have omitted critical context regarding Android OS versions and specific OEMs (e.g., Xiaomi, Huawei). OEM-specific notification proxies often re-trigger or re-sort notifications, causing redundant callbacks to the listener.
Core Cause Analysis
- Atomic Update Mechanism: When a source app calls
notify(ID, notification) and the ID already exists, the system performs an update. Even if content changes are negligible (e.g., progress bar increments or foreground service heartbeats), onNotificationPosted is triggered.
- Ranking Updates: The system re-evaluates notification priority based on user interaction or internal algorithms. Any change in the global notification rank can trigger a callback to synchronize the listener's state.
- Multi-User/Profile Environments: Notifications originating from different
UserHandle contexts (e.g., Work Profiles) may be dispatched multiple times depending on the listener's permission scope.
- Lack of Built-in Mutex:
NotificationListenerService provides no native deduplication. Failure to compare SBN.getKey() or SBN.getPostTime() results in duplicate processing logic within the receiving app.
Engineering Solution Logic
- Mapping Consistency (ID Validation):
Extract StatusBarNotification.getKey() as the primary unique index. This key is an immutable composite of pkg | id | tag | user.
- State Machine Defense (Content Validation):
Implement a content-hashing mechanism for Notification.extras (specifically android.title and android.text). If the Key matches and the content hash is identical, the event must be classified as a "Silent Update" and discarded.
- Extreme Value Defense (Time-Windowing):
To counter OEM-specific bursts of callbacks, implement a temporal filter based on getPostTime(). Subsequent events with the same Key within a specific threshold (e.g., <100ms) must be dropped.
- Explicit Scoping (Group Handling):
Explicitly check SBN.isGroupSummary(). Depending on business requirements, you must filter out summary notifications to avoid double-counting the individual child notifications and their aggregate.
duplicate notifications were sent each time, and the reason maybe android itself sent silent notification update for certain reason, according to gemini's response (attached).
So, maybe hash(pkg | id | tag | user) is necessary.
Logical Fallacies & Premise Identification
onNotificationPostedfrequency maps toNotificationManager.notify()calls, not to the number of visual alerts perceived by the user.StatusBarNotification(SBN) unique identifier (Key) and its payload. The fact that multiple apps exhibit this behavior confirms it is an intended API design, not a logic error.Core Cause Analysis
notify(ID, notification)and the ID already exists, the system performs an update. Even if content changes are negligible (e.g., progress bar increments or foreground service heartbeats),onNotificationPostedis triggered.UserHandlecontexts (e.g., Work Profiles) may be dispatched multiple times depending on the listener's permission scope.NotificationListenerServiceprovides no native deduplication. Failure to compareSBN.getKey()orSBN.getPostTime()results in duplicate processing logic within the receiving app.Engineering Solution Logic
Extract
StatusBarNotification.getKey()as the primary unique index. This key is an immutable composite ofpkg | id | tag | user.Implement a content-hashing mechanism for
Notification.extras(specificallyandroid.titleandandroid.text). If the Key matches and the content hash is identical, the event must be classified as a "Silent Update" and discarded.To counter OEM-specific bursts of callbacks, implement a temporal filter based on
getPostTime(). Subsequent events with the same Key within a specific threshold (e.g., <100ms) must be dropped.Explicitly check
SBN.isGroupSummary(). Depending on business requirements, you must filter out summary notifications to avoid double-counting the individual child notifications and their aggregate.