No notification for RCS message

[badele]

SpamBlocker version

4.6

Android version

15

The issue

RCS Message Notification Issue

First of all, a big thank to @aj3423 for this project! SpamBlocker is clean and efficient 👏

Issue Description

It seems that SpamBlocker does not notify incoming RCS messages.

Steps to Reproduce

1. I tested on two devices: Samsung S22 and Pixel 8.
2. In both cases, no notification is received for RCS messages.
3. To verify, I used Google Messages (which supports RCS) and selected a contact while forcing messages to be sent as SMS/MMS only.
4. In this case, notifications work correctly.

Additional Information

• I checked the closed issues and didn’t find a similar report.
• SpamBlocker works fine for Call and SMS/MMS messages.

[aj3423]

Just did a quick search, RCS is a standard protocol, but it's implemented differently by stock apps.

• This is how Samsung Messages handles RCS:
  https://stackoverflow.com/a/37067809/2219196

  <uses-permission android:name="com.samsung.rcs.im.READ_PERMISSION"/>

• And this is how Google Messages implements it:

      <receiver
          android:name="com.google.android.apps.messaging.shared.receiver.IncomingRcsEventReceiver"
          android:exported="true">
          <intent-filter>
              <action android:name="rcs.intent.action.incomingChatMessage"/>
              <action android:name="rcs.intent.action.incomingGroupChat"/>
              <action android:name="rcs.intent.action.incomingFileTransfer"/>
              <action android:name="rcs.intent.action.fileTransferMetadataUpdate"/>
              <action android:name="rcs.intent.action.newEvent"/>
              <action android:name="rcs.intent.action.locationReceived"/>
              <action android:name="rcs.intent.action.debugOptionResetRcsConfigResponse"/>
              <action android:name="com.google.android.ims.ZERO_SESSION_ID"/>
              <action android:name="rcs.intent.action.reportCurrentDebugState"/>
              <action android:name="rcs.intent.action.incomingConversationSuggestionsMessage"/>
              <action android:name="rcs.intent.action.incomingFileTransferPreviewUpdate"/>
              <action android:name="rcs.intent.action.incomingFileTransferCompleted"/>
          </intent-filter>
      </receiver>

• And it's not yet impleminted in Fossofy Messages: https://github.com/FossifyOrg/Messages/discussions/34

So the RCS is app-specific, which can lead to maintenance issue, and it's not that important. I decide not to support it.

[badele]

@aj3423 No problem if you don't support the RCS protocol—I understand that—but it still creates an issue.

On my Pixel 8, my default messaging app is Google Messages, which handles both SMS and RCS.

SpamBlocker recommends disabling SMS notifications from the default messaging app to avoid duplicate notifications. However, if I do this, I will no longer receive notifications for messages sent via the RCS protocol.

If RCS is not supported, it would be helpful for SpamBlocker to indicate that RCS messages are not handled and suggest two possible solutions:

• Allow duplicate notifications to ensure RCS messages are received.
• Modify contacts to switch them to Full SMS mode (which is the option I will use).

[aj3423]

Done.

[badele]

Done.

You are the best ! 💪 👏 👏 👏

[badele]

Coincidence, today, in France, our four main operators now support the RCS protocol, which means that 82 million mobile phones (for 67 million inhabitants) will not be able to fully use SpamBLocker :)

https://next.ink/173545/rcs-le-remplacant-du-sms-enfin-disponible-chez-les-quatre-operateurs-francais/

[aj3423]

I'll put some notes here for future references, just static analysis, not tested.

Here's how the latest Samsung Messages handles RCS:

<permission
    android:name="com.samsung.rcs.im.READ_PERMISSION"
    android:protectionLevel="signatureOrSystem"/>

This permission is defined as signatureOrSystem, meaning, this permisson can only be used by system apps or Samsung apps(the signature means Samsung apk signing signature).
Which means SpamBlocker won't be able to use it.

And here's how it utilizes this permission:

<receiver
	android:name="com.samsung.android.messaging.service.services.event.rcs.RcsEventReceiver"
	android:permission="com.samsung.rcs.im.READ_PERMISSION"
	android:exported="true">
	<intent-filter android:priority="1">
		<category android:name="com.samsung.rcs.framework.instantmessaging.category.ACTION"/>
		<category android:name="com.samsung.rcs.framework.instantmessaging"/>
		<action android:name="com.samsung.rcs.framework.instantmessaging.action.CREATE_CHAT_RESPONSE"/>
		<action android:name="com.samsung.rcs.framework.instantmessaging.action.RECEIVE_TYPING_NOTIFICATION"/>
		<action android:name="com.samsung.rcs.framework.instantmessaging.action.RECEIVE_CHAT_CLOSED"/>
		<action android:name="com.samsung.rcs.framework.instantmessaging.action.RECEIVE_NEW_MESSAGE"/>
		<action android:name="com.samsung.rcs.framework.instantmessaging.action.RECEIVE_CHAT_INVITATION"/>
		<action android:name="com.samsung.rcs.framework.instantmessaging.action.RECEIVE_CHAT_ESTABLISHED"/>
......

This receiver requires the READ_PERMISSION, there is no message content in the broadcast, there is only id. The receiver will then read the database to get the content, that's why it requires the permission.

Here's how it handles RECEIVE_NEW_MESSAGE :

In short, for Samsung Messages, even if SpamBlocker is capable of receiving an RCS notification, it won't be able to read the message content.

For Google Messages, there is similar package verification:

[badele]

I'll put some notes here for future references, just static analysis, not tested.

Here's how the latest Samsung Messages handles RCS:

<permission
    android:name="com.samsung.rcs.im.READ_PERMISSION"
    android:protectionLevel="signatureOrSystem"/>

This permission is defined as signatureOrSystem, meaning, this permisson can only be used by system apps or Samsung apps(the signature means Samsung apk signing signature). Which means SpamBlocker won't be able to use it.

And here's how it utilizes this permission:

I believe that in the future, manufacturers will have to adapt. In some countries, they won't be able to ignore notifications that will primarily rely on RCS (which is likely to be the case in France).

I’d say they will eventually need to change how RCS works. From what I understand, the current SMS handling process goes like this:

1. The hardware receives an SMS
2. It notifies the system/kernel/Android
3. Android has a notification system for SMS (apps can subscribe to it)
4. Subscribed apps can receive the SMS notification

It would make sense for RCS to follow a similar approach in the future. Otherwise, it wouldn't be practical.

Note: I'm not an Android developer, just reasoning from a general perspective.

[aj3423]

SMS works in that way for a couple of reasons:

• It's implemented by Android, it's saved in a built-in database.
• It's small, up to 256 bytes, so the notification can hold the entire data.
• The OTP is commonly used by other apps.

RCS is more like MMS:

• When a third-party app receives a new message notification, it only contains the id, no content.
• It needs to query the database to get the content

Those proprietary apps are already following this pattern, they just don't allow other apps to access their databases, and I don't see any reason why they would allow that in the future.

However, I see people discussing RCS support in the Fossify Messages repo, it's not implemented yet. As more carriers come on board with RCS, perhaps they will implement it later, hopefully without such restriction.