[PR #1097] [MERGED] Handle RCS messages properly, and improve group MMS #1029

New issue

Closed

opened 2026-02-26 01:32:40 +03:00 by kerem · 0 comments

kerem commented

2026-02-26 01:32:40 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/jberkel/sms-backup-plus/pull/1097
Author: @locofocos
Created: 4/23/2023
Status: ✅ Merged
Merged: 10/28/2024
Merged by: @kurahaupo

Base: master ← Head: master

📝 Commits (10+)

1bfc09d Get it compiling both via CLI (JavaVersion.VERSION_1_8 change) and Android Studio (everything else)
1643bdf Get RCS working
e512041 Fix buggy behavior with group texts. Include everyone in to/from list, plus the subject.
35dd9ec Mostly fix bug, where a single thread would get multiple gmail threads
d9ef19f Fix bug more fully, where a single thread would get multiple gmail threads, due to grabbing the contact ID from a random person in each thread
ab80cc0 Version the MESSAGE_ID hash generation so users can fix old messages
26fc10f Fix grouping for case of message thread with 1 person, both SMS and MMS (some messages have images)
bec0a00 Fix bug introduced by last commit. Ensure RCS message with 1 person is not broken into 2 threads
ac71d55 Cleanup. Parse addresses listed as "CC" for incoming RCS messages. This worked before, but now avoids a warning log
20023d9 compile support for arm64 (like pixel 8)

📊 Changes

7 files changed (+200 additions, -67 deletions)

View changed files

📝 app/build.gradle (+4 -3)
📝 app/src/main/java/com/zegoggles/smssync/mail/HeaderGenerator.java (+9 -4)
📝 app/src/main/java/com/zegoggles/smssync/mail/MessageGenerator.java (+95 -9)
📝 app/src/main/java/com/zegoggles/smssync/mail/MmsSupport.java (+85 -47)
📝 build.gradle (+6 -1)
📝 gradle.properties (+0 -1)
📝 gradle/wrapper/gradle-wrapper.properties (+1 -2)

📄 Description

Fixes #1055 and #1027

This fixes RCS importing 🎉

It also improves how group MMS threads are imported. Basically it includes all the recipients in the "to" field, and puts everyone's name in the subject, so that gmail does a much better job mimicking the group threads on your phone.

I've been toying around with it on my Pixel 3a running Android 10. I've tested with a mix of SMS, group MMS chats, and RCS chats.

I'm completely open to the idea that I was a little heavy-handed with my refactor. I ran with what made sense. I'm fine if someone else wants to take this as as proof-of-concept and run in a slightly different direction to make this mergeable.

Testing

Tips for testing:

If you want to try running this multiple times and tweaking how we generate ids/subjects/etc, make sure to delete your emails generated from testing AND empty gmail's trash. Otherwise gmail will cache things. I saw it caching the REFERENCES field when I re-used the same MESSAGE_ID.
Once you've identified some messages on your phone for a certain test case, it can be helpful to just process those messages. You can hardcode timestamps in the queries in app/src/main/java/com/zegoggles/smssync/service/BackupQueryBuilder.java. https://www.epochconverter.com/ is your friend here.

Some test cases that I've gone through on my phone, and verified that the backup looks correct in Gmail:

RCS message with 1 person. working as of bec0a004
RCS message with multiple people. Working as of bec0a004
MMS thread with lots of people going back and forth. working as of bec0a004
Message with 1 person, both SMS and MMS (texting a non-RCS user, but sometimes sending images).
- Less than 100 messages. working as of bec0a004
- At least 100 sms messages before the MMS got backed up. Not working, but you won't see it break as long as you backup frequently
  - Unfortunately we'll probably have to live with this limitation. In theory it could be fixed, but it would require processing SMS and MMS messages interleaved, from oldest to newest. Those are pulled from two separate data sources and two queries, see BackupItemsFetcher.getItemsForDataType and Consts.MMS_PROVIDER / SMS_PROVIDER. So we would have to build some intermediate caching mechanism that gathers all the SMSs, gathers all the MMSs, interleaves them, then feeds them into the existing logic.
  - I tried using the "only backup 100 at a time" setting. Unfortunately it looks like this processes batches of SMSs first, then starts processing MMSs once the SMSs are exhausted. So it doesn't help.

Adopting this new version

Here is my 2 cents for how affected users could get their backups into a clean-ish state:

The "I don't care" way: just start using the new version, and everything going forwards will be fixed.
The lazy way: just reset the backup state (or reinstall the app), back up everything again, and deal with duplicates in gmail.
The harder way: Go into Gmail and update all existing emails with label old-backups. Download the new app version. Reset the backup state (or reinstall the app) and backup everything again (to your favorite label, like SMS). For whatever time period you still have on your phone, delete emails from that time period with label old-backups. Verify that you have a nice continuity when looking at both old-backups and SMS. Then change all the old-backups emails over to the SMS label.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jberkel/sms-backup-plus/pull/1097 **Author:** [@locofocos](https://github.com/locofocos) **Created:** 4/23/2023 **Status:** ✅ Merged **Merged:** 10/28/2024 **Merged by:** [@kurahaupo](https://github.com/kurahaupo) **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (10+) - [`1bfc09d`](https://github.com/jberkel/sms-backup-plus/commit/1bfc09dc671d23df00150519ad0159cbe7f53383) Get it compiling both via CLI (JavaVersion.VERSION_1_8 change) and Android Studio (everything else) - [`1643bdf`](https://github.com/jberkel/sms-backup-plus/commit/1643bdfaa2ad6ea247ff1b6498d1d1ef3cdf3254) Get RCS working - [`e512041`](https://github.com/jberkel/sms-backup-plus/commit/e5120416560171d9f7de9a42b188190bd864fcd7) Fix buggy behavior with group texts. Include everyone in to/from list, plus the subject. - [`35dd9ec`](https://github.com/jberkel/sms-backup-plus/commit/35dd9ec098cbdfcd79a62eedb883862bccefd34e) Mostly fix bug, where a single thread would get multiple gmail threads - [`d9ef19f`](https://github.com/jberkel/sms-backup-plus/commit/d9ef19f543ea6577a685f31d2235e8dfb2eb4898) Fix bug more fully, where a single thread would get multiple gmail threads, due to grabbing the contact ID from a random person in each thread - [`ab80cc0`](https://github.com/jberkel/sms-backup-plus/commit/ab80cc0788714231fe1f25d615ebe9c375ff0224) Version the MESSAGE_ID hash generation so users can fix old messages - [`26fc10f`](https://github.com/jberkel/sms-backup-plus/commit/26fc10fab845f6c7980daf70faad164b277f4667) Fix grouping for case of message thread with 1 person, both SMS and MMS (some messages have images) - [`bec0a00`](https://github.com/jberkel/sms-backup-plus/commit/bec0a004277078f2aefb54fc6c6d614fbd4c45d3) Fix bug introduced by last commit. Ensure RCS message with 1 person is not broken into 2 threads - [`ac71d55`](https://github.com/jberkel/sms-backup-plus/commit/ac71d552e624e7b492b7fcc6ede18aa4107d7d42) Cleanup. Parse addresses listed as "CC" for incoming RCS messages. This worked before, but now avoids a warning log - [`20023d9`](https://github.com/jberkel/sms-backup-plus/commit/20023d9b21e5c6d555eb11ebeeb26e4a172e0660) compile support for arm64 (like pixel 8) ### 📊 Changes **7 files changed** (+200 additions, -67 deletions) <details> <summary>View changed files</summary> 📝 `app/build.gradle` (+4 -3) 📝 `app/src/main/java/com/zegoggles/smssync/mail/HeaderGenerator.java` (+9 -4) 📝 `app/src/main/java/com/zegoggles/smssync/mail/MessageGenerator.java` (+95 -9) 📝 `app/src/main/java/com/zegoggles/smssync/mail/MmsSupport.java` (+85 -47) 📝 `build.gradle` (+6 -1) 📝 `gradle.properties` (+0 -1) 📝 `gradle/wrapper/gradle-wrapper.properties` (+1 -2) </details> ### 📄 Description Fixes #1055 and #1027 This fixes RCS importing 🎉 It also improves how group MMS threads are imported. Basically it includes all the recipients in the "to" field, and puts everyone's name in the subject, so that gmail does a much better job mimicking the group threads on your phone. I've been toying around with it on my Pixel 3a running Android 10. I've tested with a mix of SMS, group MMS chats, and RCS chats. I'm completely open to the idea that I was a little heavy-handed with my refactor. I ran with what made sense. I'm fine if someone else wants to take this as as proof-of-concept and run in a slightly different direction to make this mergeable. ## Testing Tips for testing: - If you want to try running this multiple times and tweaking how we generate ids/subjects/etc, make sure to delete your emails generated from testing AND empty gmail's trash. Otherwise gmail will cache things. I saw it caching the REFERENCES field when I re-used the same MESSAGE_ID. - Once you've identified some messages on your phone for a certain test case, it can be helpful to _just_ process those messages. You can hardcode timestamps in the queries in `app/src/main/java/com/zegoggles/smssync/service/BackupQueryBuilder.java`. https://www.epochconverter.com/ is your friend here. Some test cases that I've gone through on my phone, and verified that the backup looks correct in Gmail: - RCS message with 1 person. **working as of bec0a004** - RCS message with multiple people. **Working as of bec0a004** - MMS thread with lots of people going back and forth. **working as of bec0a004** - Message with 1 person, both SMS and MMS (texting a non-RCS user, but sometimes sending images). - Less than 100 messages. **working as of bec0a004** - At least 100 sms messages before the MMS got backed up. **Not working, but you won't see it break as long as you backup frequently** - Unfortunately we'll probably have to live with this limitation. In theory it could be fixed, but it would require processing SMS and MMS messages interleaved, from oldest to newest. Those are pulled from two separate data sources and two queries, see `BackupItemsFetcher.getItemsForDataType` and `Consts.MMS_PROVIDER` / `SMS_PROVIDER`. So we would have to build some intermediate caching mechanism that gathers all the SMSs, gathers all the MMSs, interleaves them, then feeds them into the existing logic. - I tried using the "only backup 100 at a time" setting. Unfortunately it looks like this processes batches of SMSs first, then starts processing MMSs once the SMSs are exhausted. So it doesn't help. ## Adopting this new version Here is my 2 cents for how affected users could get their backups into a clean-ish state: - The "I don't care" way: just start using the new version, and everything going forwards will be fixed. - The lazy way: just reset the backup state (or reinstall the app), back up everything again, and deal with duplicates in gmail. - The harder way: Go into Gmail and update all existing emails with label `old-backups`. Download the new app version. Reset the backup state (or reinstall the app) and backup everything again (to your favorite label, like `SMS`). For whatever time period you still have on your phone, delete emails from that time period with label `old-backups`. Verify that you have a nice continuity when looking at both `old-backups` and `SMS`. Then change all the `old-backups` emails over to the `SMS` label. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>