Fix #82: Filter blocked contacts from notification query

[navneetsingh-dev]

The getNotificationQuerySql method was previously fetching all unread incoming messages, including those from blocked contacts. This commit injects a ParticipantColumns.BLOCKED = 0 check to ensure blocked messages do not trigger system notifications or audio alerts.

[navneetsingh-dev]

all the changes made in the file are functional and had finally resolved

[RankoR]

The normal SMS path already calculates blocked and stores the message with:

seen = read || messageInObservableConversation || blocked

Therefore blocked SMS messages already fail the existing seen = 0 condition. When the query returns no rows, BugleNotifications.createMessageNotification() enters its state == null branch and independently calls playObservableConversationNotificationSound() whenever the conversation is observable.

I reproduced this with the PR installed as the default SMS app:

• block sender;
• open the blocked conversation;
• receive another SMS;
• database row: seen=1, blocked=1;
• old and new query predicates both match zero rows;
• log reports No unseen notifications;
• there is no active Messaging notification;
• MediaPlayer / AudioTrack still runs and delivers the notification audio.

The issue also covers secondary profiles, but SmsReceiver.onReceive() directly calls postNewMessageSecondaryUserNotification() before this database query and without checking the sender's blocked state.

Please retain the query filter if desired, but gate the observable-conversation sound and secondary-user notification using the receive-time, per-sender blocked decision. ProcessDownloadedMmsAction should also include blockedSender when setting mms.mSeen.

Regression tests should cover blocked/unblocked SMS while focused and in the background, secondary profiles, manually downloaded MMS, and per-sender blocking in group conversations.

[navneetsingh-dev]

Thanks for the incredibly detailed review and for mapping out the reproduction steps! I clearly see the architectural gap now: while the SQL filter handles the standard notification query, the observable-conversation audio and the secondary-profile broadcast logic are bypassing it.

Here is my plan for the next commit:

1.Retain the current SQL query optimization for standard view consistency.

2.Gate the playObservableConversationNotificationSound in BugleNotifications by checking the sender's blocked status.

3.Gate postNewMessageSecondaryUserNotification in SmsReceiver.onReceive() using the receive-time blocked decision.

4.Update ProcessDownloadedMmsAction so that mms.mSeen accurately includes blockedSender.

I will get to work on these additions and make sure to run the full regression testing matrix (foreground/background, secondary profiles, manual MMS, and group thread blocking) before pushing the updated branch. Thanks again for the guidance!

[navneetsingh-dev]

Thanks for the incredibly detailed review and for mapping out the reproduction steps! I clearly see the architectural gap now: while the SQL filter handles the standard notification query, the observable-conversation audio and the secondary-profile broadcast logic are bypassing it.

I have pushed a new commit that:

1.Retains the current SQL query optimization for standard view consistency.

2,Gates the playObservableConversationNotificationSound in BugleNotifications by checking the sender's blocked status.

3.Gates postNewMessageSecondaryUserNotification in SmsReceiver.onReceive() using the receive-time blocked decision.

4.Updates ProcessDownloadedMmsAction so that mms.mSeen accurately includes blockedSender.

I've run the regression testing on my end and everything is behaving properly. Thanks again for the guidance!