Using RCS with Google Messages on GrapheneOS

MrRoboto1212

bebop10 now I've given up on RCS. Hopefully, in the future it works

Same boat, but T-Mobile (direct, no MVNO). Tried 15-20 solutions, and none of them have worked for me for some reason. RCS worked fine, and now Etouffee will not turn true no matter the version. I've stopped caring for now. The likelihood of someone intercepting my phone specifically and grabbing my SMS messages is pretty slim considering the rural area I live in.

I'd rather not put in a mountain of effort and time to either 1. do the repetition every 36 hours or 2. have it break once again a month later and now I'm back at square one and did all of it for nothing.

Prioritization for issues by the team has been talked about a bunch in this thread already, but I'll reiterate: For how privacy and security-centric GOS is as well as claims to be, you would think RCS functionality would be towards the top of the bug fix list. - Not saying I don't appreciate all of the work the team does, but this point has been made before in the thread.

Other than the RCS stuff, I'm loving GOS. Thankfully RCS isn't a must-have for me like many others.

Gramsci

MrRoboto1212

It is not a bug but rather a feature request, as already clarified above. Happy to discuss further if you are not able to grasp why after reviewing the previous posts (with links to various github issues that elaborate the distinction in detail) in this thread.

With that said, things will likely start to look quite a bit more interesting from a privacy/security standpoint very shortly: https://medium.com/macoclock/why-ios-26-3-is-the-most-important-privacy-update-in-years-e1e66a088625

morapelor

Gramsci

If a basic feature works on stock OS, but it does not in GOS, it is a bug. You can be as snide and snotty about it as you'd like, and you sure are and sure help yourself to it, but this is a very plain fact. If cellular calls did not work in GOS would you call that a feature request to make your phone be able to place telephone calls? That's your claim.

ZenIsFluffy

ZenIsFluffy I lied when I said I was giving up. I have no idea what exactly I've done, or if it will continue, but RCS has stayed active for over 48 hours so far on T-Mobile for me. On the latest version of Google Messages from the Play Store.

I installed Carrier Services from Google Play. It installed but was disabled. The enable button in settings did nothing. I enabled it using ADB pm enable com.google.android.ims
I uninstalled Google Messages and cleared its storage. Installed the 2024 version mentioned in this thread. Allowed the permissions and set as default. Then I opened it and signed into my Google account. Finally rebooted my phone.
After that, I updated to the latest from the Play Store. I don't recall what it said in settings. The Report RCS option in Debug menu now says "Report Multi SIM RCS Connection State" despite only having one SIM.
This gave me an idea. I have a Verizon eSIM from US Mobile. I transferred it to my Pixel 8 Pro. Rebooted.
Suddenly both SIMs were connected, and I could RCS message with both of them. It's been 48 hours, so we're moving into day 3 with T-Mobile being active. Coming from having to reactivate every 24 hours, that's an improvement.

I'm still holding out for a future where this will work normally. But I'm doubtful this industry standard Google has co-opted into their own monster will be slain anytime soon ;-;

ZenIsFluffy

ZenIsFluffy I shouldn't have said anything because today it stopped working for T-Mobile LOL. Ah well!

Somewhereover88

For anyone on spectrum mobile, I've tried every fix possible to no avail.

alwarnecke

Somewhereover88 I'm on Spectrum Mobile as well. Pixel 7. I installed version version messages.android_20241120_00_RC07.phone_dynamic, I did the apk bundle with APKMirror installer. Installed in November and RCS has been working ever since. Make sure you do the usual permissions set up (set as default SMS app, allow Network, SMS, Phone, Notifications, Contacts) before opening for the first time.

jumpdeer

I am reverting to stock as group chats are too important for me right now. I hope this feature can come sooner rather than later, because I really enjoy using GOS.

cb474

Well, I'm almost at 72 with no reset and RCS continuing to work.

I was looking again at what anorak said worked for them. One of their steps was to allow READ_DEVICE_IDENTIFIERS for Google Play Services. I had not bothered to try this, even though it has been discussed a lot over the course of this thread, because my understanding was Google Play Services should be getting this information anyway (although I'm not totally sure about this). But then I was looking again at the bug report for this issue in Graphene, https://github.com/GrapheneOS/os-issue-tracker/issues/6331, which explicitly states the problem has to do with Messages not being able to READ_DEVICE_IDENTIFIERS. So I thought I may as well try this.

What I did was:

1) After the 36 hour reset with Messages, but before installing 20241120_00_RC07, I set READ_DEVICE_IDENTIFIERS to allow for Google Play Services.

adb shell appops set com.google.android.gms READ_DEVICE_IDENTIFIERS allow

I don't honestly remember if I had already uninstalled Messages or just did this before I started any of the steps of the 36 hour reset process. Sorry.

I did not set READ_DEVICE_IDENTIFIERS to allow for com.google.android.ims (Carrier Services) as @anorak mentions, because my understanding is that Carrier Services is not the issue and I don't have Carrier Services installed anyway. @ZenIsFluffy's experience a few posts up, regarding Carrier Services, is interesting, but difficult to tell which thing they did actually helped. Also I wanted to only change one thing at a time, to be scientific about this.

2) After that I installed 20241120_00_RC07 as usual, set is as the default SMS app, and got to "connected."
3) Then I updated to 20250311_04_RC01 as usual. I did notice that it immediately got Etouffee to "true," rather than having to reboot a couple times, as I have had to lately.

That's it. I did all this almost 72 hours ago.

I do wonder if this means that if I updated to the Play Store version it would keep working. But I'm also hesitant to jinx anything. Separately, a few people said that the 36 hour reboot started again after a recent update to Graphene. I do wonder if something changed with permissions on READ_DEVICE_IDENTIFIERS and that brought the 36 hour reset problem back.

Anyway, I hope this works for other people and helps.

eatinggrumble84

cb474

I do recall allowing this Device Identifiers permission in the past when RCS first started breaking around October. I don't recall it being a fix at that time. Looking now, it is now denied when it was previously staying as allow. I currently have the latest Messages version installed from the app store after first installing 20241120_00_RC07 as usual, but skipping 20250311_04_RC01. Going straight to the latest update did allow me to enable RCS again earlier today. I have just now set READ_DEVICE_IDENTIFIERS to allow using App Ops and Shuzuku and I've only rebooted my phone but have left Messages installed as it had been. I'll see if it stays working beyond 36 hours this way. If not, I'll try the reinstall after making sure the READ_DEVICE_IDENTIFIERS remains allowed.

aaravchen

cb474

I jumped back to DirtyDan's old method, that shares the first install setup with Turtacular's method: installing the specific old version, wiping data and setting up permissions before opening, getting RCS Connected, then updating to the latest from the store.
I didn't have to do anything with ADB. GOS Adkins even mentioned that the READ_DEVICE_IDENTIFIERS is configured to be automatically granted to the default SMS app if GPlay services are installed, so I don't think setting it manually will do anything.

I'm at 48 hours with no loss of RCS now on T-Mobile. I've been having to redo the installs every 24-36 hours for the last 3 weeks up until now.
It looks like T-Mobile must have changed thier authentication/authorization policies so things are actually working well now (knocks on wood).

cb474

eatinggrumble84 That's interesting if READ_DEVICE_IDENTIFIERS for Play Services previously said allow, without any user intervention, but now has changed to ignore for some reason. I never did anything with READ_DEVICE_IDENTIFIERS before, so I don't know what the prior state of it was on my phone for Play Services, before I had the return of the 36 hour problem.

I will be really interested to hear if the Play Store (latest) version of Messages stays connected beyond 36 hours. Please report back.

eatinggrumble84

cb474
I did intervene months ago with changing it to allow. The previous default state was deny. But at some point it changed back to deny. I'm not sure when or if it was a GOS update that flipped it back. From what I read call, the change to allow months ago wasn't what fixed RCS though, but hopefully it's the fix now.

eatinggrumble84

cb474
It is now beyond 36 hours with the latest Play store version, and having set the READ_DEVICE_IDENTIFIERS to allow after already having the latest play store version installed. My RCS was connected and working at the time, and I did not need to uninstall and reinstall the 20241120_00_RC07 after setting the device identifiers permission.

I don't want to jinx it because others here have seemingly not had issues with it beyond 36 hours only for it to then stop working within a couple days.

Edit: I just read your more recent comments. I too am on T-Mobile so it could be a coincidence with their back end, but in my case, the 36 hour reset seems to have stopped after setting the device identifier permission to allow. Either way, I think you should be fine to update to the latest version.

So for anyone else reading, I got mine working with installing 20241120_00_RC07 first to get the connected status and then updating to the latest Play store version. It has stuck beyond 36 hours now which may oy may not have to do with the permission to read device identifiers or something was just updated on T-Mobile backend.

MrRoboto1212

morapelor You can be as snide and snotty about it as you'd like

Yes, this is why I myself didn't reply to this user. Didn't need to give them attention lol

If a basic feature works on stock OS

The GOS Team said they fixed this feature presumably for everyone. It worked, then it stopped. Metric tons of users are looking for a fix themselves now because it's not a priority.

A feature introduced to something which becomes broken is called a bug. Pay no mind to the person you replied to acting needlessly elegantly wordy and like a know-it-all.

Gramsci

morapelor If a basic feature works on stock OS, but it does not in GOS, it is a bug. You can be as snide and snotty about it as you'd like, and you sure are and sure help yourself to it, but this is a very plain fact. If cellular calls did not work in GOS would you call that a feature request to make your phone be able to place telephone calls? That's your claim.

This analogy relies on a fundamental misunderstanding of what GrapheneOS is. GrapheneOS is not a "skin" of the stock Pixel OS but rather it is a hardened fork of AOSP.

To be clear on the distinction that further undermines this analogy: Cellular calls utilize standard GSM/LTE/NR telephony stacks that are part of the open source base. If those fail, it is indeed a bug because the core telephony code is broken. Meanwhile, RCS is a proprietary service run by Google that rides on top of the OS, heavily dependent on Play Services having invasive system-level privileges. On stock OS, Google grants itself those privileges by default. On GrapheneOS, Play Services is sandboxed like any other app.

When RCS fails because it can't access deep system APIs that GrapheneOS deliberately restricts for security, that is the security model working. It is not a "bug" that GrapheneOS prevents Google from reading your hardware identifiers. Making RCS work requires building complex, specific compatibility machinery to bypass these restrictions safely.

Claiming "it works on stock so it should work here" ignores the entire purpose of GrapheneOS. If you want stock behavior with stock privileges, you should use stock.

uqtdev

morapelor It's not a basic feature of grapheneos though. Google Messages being broken isn't grapheneos's fault. Sure the developers of GrapheneOS could add in compatibility features to make it work, but the underlying cause IS within google messages. They werent being snide and snotty by pointing out someones misunderstandings respectfully. If anything YOU are being snide and snotting by claiming that an app that isn't made for grapheneOS itself SHOULD work directly for you.

That isn't to say that it isn't annoying that RCS doesn't work on grapheneos, Or that I dont see why you think it should be a focus of the project, but please be respectful when someone is just explaining something to you on a forum, as that's what these forums are for.

jumpdeer

Well everyone I reverted to stock Pixel OS and guess what? RCS chats won't provision and it says "RCS chat's aren't available on your device."

Perhaps this means that the carrier (T-Mobile in my case) is flagging devices/accounts?

jumpdeer

It wasn't until I updated every app that needed to be updated that it started working. This is the list of apps that I had to update. Maybe one of them is part of the equation?

https://ibb.co/mCdQNzY0

Gramsci

MrRoboto1212 The GOS Team said they fixed this feature presumably for everyone. It worked, then it stopped. Metric tons of users are looking for a fix themselves now because it's not a priority.

A feature introduced to something which becomes broken is called a bug. Pay no mind to the person you replied to acting needlessly elegantly wordy and like a know-it-all.

Actually, it is important stop conflating "bugs" with "missing compatibility features". The distinction isn't semantic but rather relates to how real-world development actually happens.

As thestinger outlined in issue #673 among other places, when a sandboxed app (like Play Services) fails because it tries to perform a privileged action that the OS deliberately blocks, that is not a code defect (bug) but rather is a gap in the compatibility layer. GrapheneOS is working exactly as designed by enforcing the sandbox.

For RCS to work, the OS doesn't need a "fix" but rather it needs an entirely new "shim" feature to proxy these privileged requests (like hardware attestation or carrier config access) safely. Depending on the current state of dev resources, prioritizing this could potentially even mean pausing essential security work to build massive workarounds for Google's proprietary stack. If you want RCS, you are requesting a new feature expansion, not a bug fix. Understanding this architecture (or at least accepting the reality of its existence as underpinning the project) is required if you want to criticize the prioritization of issues in a manner that is respectful to the GrapheneOS development team.

Gramsci

MrRoboto1212 The GOS Team said they fixed this feature presumably for everyone. It worked, then it stopped. Metric tons of users are looking for a fix themselves now because it's not a priority.

Dropping in this post from just 2 days ago as a corrective to your assertion that this isn't a priority: https://xcancel.com/GrapheneOS/status/2017258630865723888#m

cb474

aaravchen I guess it's possible that it's just a coincidence that the 36 hour reset problem stopped for me, after I gave Play Services the READ_DEVICE_IDENTIFIERS permission, but really something on the backend at T-Mobile changed.

Yes, I thought that READ_DEVICE_IDENTIFIERS was supposed to be default enabled anyway. I also had read that somewhere. But you can check it's status with adb with:

adb shell appops get com.google.android.gms

When I checked that I could see that READ_DEVICE_IDENTIFIERS for Play Services was set to deny. If I check for the Messages app itself I see that same thing; it's set to deny. Maybe somehow else it gets the permission anyway?

That is very interesting that you are on the latest Play Store version of Messages and have made it to 48 hours. Maybe I should try updating. And if that holds, then try disabling READ_DEVICE_IDENTIFIERS for Play Services and see if it still keeps working.

I wish we had more information about what was going on, causing and then resolving (maybe) the 36 hours issue. Why did it come back a couple weeks ago? Why do the things we do work or not work? If the problem has gone away on its own now, why?

« Previous Page Next Page »