Group SMS Block

[jbienz]

The feature

First, thank you for this wonderful app. You're a life saver.

Recently I've been receiving a deluge of spam texts and they are always group texts. These group texts never include anyone in my address book.

I'd love an option to immediately block any group texts that doesn't include at least one number from my contact list.

[aj3423]

I'll try to add this.

Have you ever received any group message that isn't a spam? I mean, the contact checking doesn't seem necessary. When it contains one of your contacts, it only means your contact is also spammed.

[aj3423]

Well, I thought MMS are handled in this app, but actually they aren't, that would require an extra permission: RECEIVE_MMS

A group message is actually an MMS message, not an SMS message, so this app won't show any notification for group messages.

The issue is solved :)

Since all MMS are spam to me, I'm not going to add support for MMS, but I'll inform user about this. If anyone has a proper use case, I'll consider adding support for it.

[jbienz]

Well, every holiday I get a group text message from my mom sent out to all of our family (whom are in my contact list) and to a bunch of her friends (who aren't in my contact list). This message is the primary way I get invited to Christmas or Thanksgiving dinner.

Sometimes, when I'm at a conference, I'll get a message from a contact I know inviting me to a group dinner with other contacts I don't know. I find these valuable.

Finally, I have a group message with my kids. They are of course both in my contact list.

Outside of those scenarios, all the other group messages are spam. So, I do have scenarios where I want group messages. But only if those group messages contain at least one person in my address book.

I have not yet received a message that was spam and also targeted someone in my contact list. While that may eventually happen, since group MMSs are usually limited to 20 numbers I suspect it'll be rare.

[aj3423]

every holiday I get a group text message from my mom sent out to ...

when I'm at a conference, I'll get a message from a contact I know inviting me to ...

I have a group message with my kids ...

These 3 kinds of messages are all from a contact in your address book. So what really matters is whether the sender is a contact, the other recipients don't really matter, is that right?

[aj3423]

Oh the MMS support is missing, I'll add it for receiving group messages.

[jbienz]

So what really matters is whether the sender is a contact, the other recipients don't really matter, is that right?

I believe that's correct for the majority of the time with the initial message. However, I would still want to receive the replies from contacts not in my list (e.g. ongoing conversation about where to meet for dinner).

I could potentially see a situation where a contact added my number to an existing group chat rather than initiating the group chat. In that situation, the contact wouldn't necessarily be the first message.

[aj3423]

I hate to admit that this use case is reasonable.

I'll add a new regex flag "All Recipients", when it's enabled, the regex will also check other recipients.

[aj3423]

I've tested with three phones, two different telco services, 4 SMS apps, none of them shows the other recipients. In the SMS app, I can only see the sender's number, not others. Not sure how you got that screenshot, I guess it's telco specific.

This is the entire MMS PDU:

This testing message was sent to a group of 4 people, but it only contains the sender and the receiver. Not sure what the text000001.txt means, there isn't such a file, but it seems irrelavant, it can have the same value even for different groups.

Given that it's telco specific and I can't even test it, I'll give up on this feature. And the MMS support as well, that PDU decoding library would probably increase the apk size by 300k and the MMS isn't that useful.

[jbienz]

Wow, I really appreciate you digging into this. I was quite surprised to read your findings. I can't remember a time of ever not being able to see all the recipients on a group text. Though, I have been on the same carrier (Verizon Wireless in the US) for probably 20+ years.

I did a little research on this, and from what I found this doesn't appear to be carrier (or US) specific.

Here's a SO post for how to do it, though this post is from 2018:

https://stackoverflow.com/questions/52186442/how-to-get-phone-numbers-of-mms-group-conversation-participants

I asked ChatGPT o3-mini to produce code that would be compatible with Android 14. It produced code that queries the Telephony.Mms.Addr table. I was not able to verify if this code works, but I thought I would pass it on in case it's helpful.

package com.example.mmsutils;

import android.content.Context;
import android.database.Cursor;
import android.net.Uri;
import android.provider.Telephony;
import java.util.ArrayList;
import java.util.List;

/**
 * Utility class for accessing MMS details.
 */
public class MmsUtils {

    /**
     * Retrieves all recipient phone numbers from a group MMS message.
     * <p>
     * This method queries the MMS "addr" table for the specified MMS message ID.
     * It filters out the sender’s address (usually marked by type 137) and any placeholder values.
     * </p>
     *
     * <p><b>Important:</b> To run this on Android 14, ensure your app has the appropriate
     * permissions (e.g. READ_SMS) in your manifest and that you handle runtime permission requests.</p>
     *
     * @param context The application context.
     * @param mmsId   The ID of the MMS message.
     * @return A list of recipient phone numbers.
     */
    public static List<String> getMmsRecipients(Context context, long mmsId) {
        List<String> recipientNumbers = new ArrayList<>();
        // Construct the URI for the MMS "addr" table for the given MMS message.
        Uri mmsAddrUri = Uri.parse("content://mms/" + mmsId + "/addr");

        // Query the MMS "addr" table. The projection includes "address" and "type".
        Cursor cursor = context.getContentResolver().query(
                mmsAddrUri,
                new String[]{"address", "type"},
                null,
                null,
                null
        );

        if (cursor != null) {
            try {
                // Get the indices of the required columns.
                int addressIndex = cursor.getColumnIndex("address");
                int typeIndex = cursor.getColumnIndex("type");

                while (cursor.moveToNext()) {
                    // Read the address and type.
                    String address = cursor.getString(addressIndex);
                    int type = cursor.getInt(typeIndex);

                    // In the MMS PDU, type 137 is typically the sender. 
                    // We also filter out any placeholder values like "insert-address-token".
                    if (address != null &&
                        !"insert-address-token".equals(address) &&
                        type != 137) {
                        recipientNumbers.add(address);
                    }
                }
            } finally {
                cursor.close();
            }
        }
        return recipientNumbers;
    }
}

Having said all that, if you believe this feature is too esoteric to be helpful for enough people, I do respect your decision not to add it.

[aj3423]

The answer from AI above is about getting the sender's address, and AI could be more misleading than helpful on such topics.

If I'm right about this: everything in the database comes from the PDU, then that stackoverflow post won't work.
I mean, if the PDU dosen't contain any explicit number +12223334444, it would be impossible for the phone to give us +12223334444 when we query by ID, it has never seen the number yet.

Maybe your carrier gives you all recipients' numbers in the PDU, while mine doesn't. Actually I think they should't have done it (for privacy concern).

Anyway, I'll look into it first. There's a quick way to verify if it's actually supported by my carrier, I can install your phone app and see if it also displays all recipients.

What's that app(version)?

[jbienz]

Thank you again for taking the time. I understand that AI can be misleading, especially with esoteric topics. The SO post looks promising from the user comments, but I know it's pretty old.

Maybe your carrier gives you all recipients' numbers in the PDU, while mine doesn't. Actually I think they should't have done it (for privacy concern).

Interesting your perspective. I would think that the more privacy conscious thing to do would be to inform the user of the other parties they're conversing with. I'm curious what would happen in your country if you were in a group chat with some people you know and some you do not. When someone you do not know sends a message, do you see their number accompanying the message? I'm guessing you do, but that's only because they've "participated" by sending something. I would still be uncomfortable with the idea that people I don't know could be observing what I'm sending without my knowledge.

What's that app(version)?

Phone is the Phone by Google app:

https://play.google.com/store/apps/details?id=com.google.android.dialer

The Phone app version is:

Version 159.0.721059499-downloadable

Text / MMS app is Google Messages:

https://play.google.com/store/apps/details?id=com.google.android.apps.messaging

Text / MMS app version is:

Version messages.android_20250129_01_RC00.phone_samsung_openbeta_dynamic

I am enrolled in the beta of that app, and it does appear to be a Samsung specific build. However, I have been able to view other phone numbers in group texts for years and before I entered the beta.

[aj3423]

I would think that the more privacy conscious thing to do would be to inform the user of the other parties they're conversing with.

I forgot to mention, when receiving a group message on my phone, it's alwarys represented as a regular p2p message(flagged as MMS thouth). It's impossible for me to reply to a group, I can only initiate a group message by creating the group myself.

I'm also using both of these google apps, the phone app doesn't matter, the message app is:

messages.android_20250115_03_RC01.phone_dynamic

But my google message app never shows other recipients.

From my debugging and the source code of the "Fossify Messages", the group MMS seems to work like this:

1. The carrier pushes a brief packet to the phone, it contains very few information:
   • a PDU downloading url, as an internal LAN address like: http://10.123.45.789:80/mC7511, which should only work between the phone and the telco cell.
   • and some other irrelevant IDs, but there isn't any address.
2. The phone will download the PDU from that url, it contains everything, including
   • sender
   • receiver
   • all group recipients (maybe in your case, but not mine)
   • the text, image, and other attachments
3. Android will parse the PDU, save to the database, and then notify other apps

I think your PDU contains all recipients. Can you help to dump a PDU on your phone? I can show you the steps, it would require Android Studio and git.

edit:
I'll attach the steps here for future reference.

how_to_dump_a_pdu.zip

[aj3423]

As mentioned in the stackoverflow post:

The threads table has a column called recipient_ids, this might be Space separated for group message, something like this:
123 456 789
Where 123 456 etc are the recipient ids.
Get address for respective recipient ids. AOSP uses the following uri: content://mms-sms/canonical-address

I sent a group message(4 recipients), then I dumped the entire database /data/data/com.android.providers.telephony/databases/mmssms.db, those two tables:

• threads

• canonical-address

The other two recipient numbers don't exist in any table.

I'm not going to support MMS because:

1. It's telco specific, I don't have the environment to develop and test.
2. It will complicate the app, impacting a lot of things like RepeatedCall/Dialed/UI/tooltips...
3. The PDU parser library will increase the apk a lot.
4. It's rarely used.

Btw, the PDU is not encrypted at all, which means anyone nearby would be able to see your MMS content.