Using RCS with Google Messages on GrapheneOS

cb474

MetropleX Thank you for the link to the posts on Twitter about RCS. It's helpful to see all of those comments together. However, with all due respect, there is not much information there, especially regarding the problem of some users being stuck unable to disable RCS, because of how it breaks group messages, but having RCS not work properly on their carrier.

Instead, those posts contain repeated assertions about how RCS works on Graphene except on T-Mobile and AT&T, which I believe downplays the problem for reasons I won't repeat since they've been said so many times. There are some comments about RCS not being the best solution for privacy, which is beside the point of the problems many of us have with just needing functional carrier based messaging. There is a statement about a future Graphene native RCS apps, but that sounds like a very long term project.

And then there is this statement on November 25 of last year:

Google Messages RCS should work on all carriers other than T-Mobile and AT&T. We need to implement a toggle for granting what's required by Google Messages for the current version for those carriers and their MVNOs.

Followed confusingly by this statement on December 29 of last year:

Google Messages requires extensive privileged access to provide RCS with certain carriers which is why it doesn't work with AT&T or T-Mobile. Being able to give Google Messages highly privileged access is something only a small number of people want.

I'm not sure what is going on there, but those two statements seem to contradict each other.

I'm really not trying to be disrespectful to the devs. But I don't see anything that acknowledges the specific problem of those of us with broken group chats if we disable RCS, because T-Mobile and AT&T aren't supported on Graphene, and so being stuck with hacky workarounds with old versions of Messages that could stop working at any time. We've been in this situation for almost five months. What does Graphene and the devs suggest we do?

ShoulderSurfin

aoude .. the biggest problem I have is iPhone users that are .. "I use iMessage" and refuse to use anything else except maybe WhatsApp.

cb474

Turtacular Are you also on the Signal forums? Not that it's a great solution, but their forums allow messaging.

Do you mean this forum: community.signalusers.org. I'm not on it, but I could create an account. It also looks like the privacy guides forums allow messaging, if you're on that: discuss.privacyguides.net

Turtacular

cb474 I'll reach out on PG since you already have an account there.

Gramsci

MetropleX Thanks -- I fully agree that (i) the releases and public comments by the project provide adequate information on the topic and (ii) stating the dev team has been inactive/inattentive with respect to RCS is completely inaccurate and counterproductive.

bebop10

Hi, I'd like to give my data point/experience; hopefully someone finds it helpful. I am on Google Pixel 9 Pro XL and have ATT. I have tried every solution in this thread but as of right now RCS does not work. I tried the method of downloading an older version of Google Messages and it worked for awhile but then just stopped one day and has not worked since. Right now when I check the status of RCS, this is what I see: "Status: Trouble connecting. Awaiting retry... Details: Status Code 3200. Status details: Please wait, activation is ongoing. Carrier: AT&T". I am on the latest GrapheneOS version (I know it is not Graphene's fault). And now I've given up on RCS. Hopefully, in the future it works, but I am slowly trying to move people over to Signal which is incredibly difficult.

litlelilim

The 36 hour reset has turned to more like 24 hours DX or maybe this update broke something. Feels like its been breaking sooner than 36 hours for a while now.
(T-mobile, Pixel 10)

cb474

litlelilim For me it's consistently remained at 36 hours. Although I stopped using 20250311_04_RC01 as the second version to get Etouffee to "true." I've been trying progressively newer versions to see if one lasts beyond 36 hours (with no luck). I've tried: 20250319_02_RC02, 20250326_00_RC09, 20250402_00_RC02, and 20250409_01_RC01. They've all gotten Etouffee to "true," but also all reset at 36 hours.

If you're not experimenting like me and you're not already doing the following, I think it probably makes sense, after you use 20241120_00_RC07 to get RCS "connected," to then just update to the current Play Store version to get Etouffee to "true." I assume it will reset at 36 hours. But at least then you are using the most current version of Messages with all the security updates and bug fixes.

ax898

I have a pixel fold 10 with tmobile (directly, no mvno). And unfortunately I have to return this phone and switch back to my older samsung phone as RCS is a must-have to communicate with my friends and family.

That being said, I spent some time looking into it. I have some observations.

I created a custom build of GOS and added a current version of Google Messages as a privileged system app. I confirmed it has all the permissions it specified. Yet I still ran into the same issue of not being able to connect RCS. It gave the same logcat error of not finding any phone numbers. I assume the issue is somewhere with unprivileged google play services. I thought about installing that as a privilege service, but at that point I may as well just run stock os. So I didn't try it.
I read through a lot of this thread and there's a lot of discussion around single registration model vs dual registration. The logcat messages say (at least for my tmobile sim) that single registration is not allowed. This is verified by looking at the effective carrier config dumped by Google Messages (via debug menu) and looking for the "ims.ims_single_registration_required_bool" key. It was false for me. So from my understanding that whole aspect shouldn't play into this at all. It's still using a dual-registration model but something else has changed.
The MicroG project has had a bounty for RCS support since last year. The bounty has grown to 15k USD so far, https://github.com/microg/GmsCore/issues/2994. A number of people have been working to reverse engineer how google messages performs its provisioning and auth, but there hasn't been any success so far. There are concerns that there is hardware attestation involved.
Recently there was an article in Hacker News about RCS. https://news.ycombinator.com/item?id=46687841 There are a lot of interesting comments as well and is a good read for those interested in RCS. I can't verify the content of the comments, but they seem to indicate this issue is a much more involved issue than simply granting permissions. Again, there are a few stating that hardware attestation is required.

I really hope GOS devs are able to get this running. I'd love nothing more than to switch back to Graphene OS. But it appears google has really locked this down. There's nothing open about RCS. In actuality they own the entire stack. It's a proprietary product masquerading as an open standard for marketing purposes.

cb474

ax898 That's very interesting and a little depressing that it's so complicated. I saw the thread last week on Github with the bounty for solving the RCS problem on Microg. It seems like there was a lot on enthusiasm for a while, but their efforts eventually got stymied and not much has happened for a while, despite the large bounty.

I do wonder, if there are all the constraints you suggest on getting RCS working. Then why are people able to get around them by using old versions of Messages? It seems like the issue is more in the app, than in the backend or play services. Yes? No?

ax898

cb474

Unfortunately I don't think anyone outside of google can answer that question. If I were to speculate, I'd probably say the older app version is using an older api version that is more permissive than the current version.

Google Messages (at least for my tmo sim) is using tachygram as the backend protocol. Which is googles proprietary messaging service and not gsma rcs. In this world, anything goes.

I could see a world where the service for initial provisioning is distinct from the service handling refreshes. If the initial provision service accepted connections from the old version, but the refresh service didnt, you could definitely end up with the current 36 hour limitation.

Google can deploy or rollback changes to these services whenever they wish. Perhaps that week long outage a few weeks ago was result of this.

But again, this is all speculation. Your guess is as good as mine.

jumpdeer

anorak This has not worked for me, though I didn't run the adb shell commands since it is almost certainly unnecessary.

« Previous Page