it would be good to have rcs enabled in few cases where sms is still used , for example bank otp messages and other services which still rely on sms as an authentication mode , could now be sent more securely. Though not sure exactly if rcs would be safe from impersonation attacks.
Google Messages and RCS does work on GrapheneOS.
There is a permission change I had to make to get it to work however.
Specifically:
adb shell appops set com.google.android.gms READ_DEVICE_IDENTIFIERS allow
This is because the Google Messages app needs access to IMEI.
The state of the permission can be found with:
adb shell appops get com.google.android.gms | grep READ_DEVICE_IDENTIFIER
this still did not work for me unfortunately, this did not maintain it nor connect.
I use the workaround of installing an older version of Google Messages to connect then updating the app.
I know. But not always. Thatâs why I did not say that Google Messages and RCS does not work on GrapheneOS⌠thatâs why I said âlike for a lot of GrapheneOS users, I canât set up RCS on Google MessagesââŚ
1 Like
What is incorrect? On Android, there is only Google Messages (or Samsung Messages). I donât think RCS is open-source or that any app can use some sort of Android RCS API.
1 Like
RCS isnât open source itâs an open standard if you got those mixed up, at least I hope im wrong but yeah.
and exactly what I said, there is no like Android RCS functions or anything for apps to interface with, like how Google provides for SMS.
All standards are open, but judging how Samsung Messages didnât even work well with Google Messages, the implementation doesnât seem truly inter-compatible.
Furthermore, the standard is highly-complex meaning only the few can develop it, with no guarantees other will accept their requests.
I didnât know there was an Android API for SMS but this make sense.
This is something Iâd like to understand better. AFAIK RCS is an open standard and RCSâs Universal Profile is intended to be a standard/specification that can be implemented by any.. carrier(?) messaging app developer(?).
For a long time an impediment was that encryption was not part of the RCS standard or the Universal Profile spec. But that has recently changed as of Universal Profile 3.0. I wonder whatâif anyâbarriers exist to prevent independent open source messenger apps from adopting/supporting RCS and the Universal Profile w/ MLS encryption. Are the little guys being shut out, if so is that intentional or an unintended consequence of something else, or is it all simply just too new or too much work for smaller players to have had time to implement RCS support?
edit: 6 years of relevant but not super conclusive discussion from the QKSMS github.
1 Like
Wasnât this only published this month? Even if there were no barriers at all it seems unlikely that an independent open source messenger app would be ready this quickly.
The one I have read about are that carriers may have exclusive agreements with certain RCS providers. Although most of that is through Reddit threads so its hard to say what the voracity of that info is.
I believe that 3.0 (which is the first to include encryption) was published within the last 2 months. So you may be right that this is early days, and itâll just take some time.
On the hand, encryption is the killer feature that matters to us and our little niche of privacy conscious folks. But RCS in general brings a lot of other advantages and quality of life upgrades that are equally or more important than encryption for mainstream users, including mainstream many tech enthusiasts, and the developers who are targeting a mainstream userbase. So theoretically, regardless of encryption, there has been a lot of incentive for 3rd party messengers to implement RCS if it was somewhat feasible/simple to do so, simply to compete with iMessage or Google Messages in terms of features.
I really hope that you are right, and that the introduction of encryption to the Universal Profile, will bring a renewed interest and enthusiasm for RCS support by 3rd party app developers, and we will see some independent options in the coming year. 
Unfortunately there is no conclusive answer to give.
But all we know for sure and as I said before Iâve actually been trying to research this hoping to find a way to implement RCS to no avail, so again I would not expect any clients or forks like I wanna do utilizing RCS
as for whatâs nothing stopping them, same thing, No conclusive answer other than what I can think of, which is I think at nothing, SMS/MMS Is an open standard, Google provides the API to android to be able to send/receive them thatâs why we have a buttload of sms/mms apps but yeah.
I did saw someone where they theorized that if they opened RCS to everyone, we would probably end up in this carrier only app works kind of limbo and there might be some merit to it however I donât see how they still couldnât do it unless Iâm missing something
RCS Used to connect to Google Jibe Mobile which was the closest we got to standardized server only to later close down for carrier support or something. If something else of a theory, Maybe Google is working on it in the background for the next Android versions? Or until things standardize properly (like They stay at Universal Profile 3.0) and then put it on the next Android versions and i turn the Android Development SDK, Could be, Could be not. Just a theory.
And thereâs that I case, the carrier support for RCS, Being finicky means thereâs no way to send standard SMS? But I diagress there could still be things like boolean IsRCSConnected function/variable for example to solve that so idk there just isnât that.
Honestly hate that it hasnât been released as an open standard so that it can be implemented into other apps. I feel like it is simply a way to lock people in even more into their ecosystem. After all, google msgs and apple msgs are default on their respective devices. Other messengers donât have a proper chance to compete 
RCS is not an open standard, that is just fluff.
Say no to vendor lock-in, say no to RCS!
6 Likes
exactly how is it not an open standard
If Samsung and Apple and Google can utilize it, it definitely isnât a vendor lock-in.
If it was just Google, Understandable but when more companies are using it, thatâs false.
Apparently there was a test client for AOSP introduced around the time of Android 12, called TestRCSAPP. Doesnât seem to be a lot of information available about it. Does anyone have any knowledge or context about it?
Can you elaborate on your perspective, what makes it not an open standard?
1 Like
I think I have seen about this.
I donât have much context other than my theory or Google is waiting before rolling it out may or may not be true. But I could be wrong and this is different, maybe Iâm confusing it with ImsRcsManager | API reference | Android Developers
but at that.
There is no reason it shouldnât work if it works with stock OS. You must not have the right permissions set or something. It only works in the Owner profile as well.
That method doesnât work reliably anymore, people said there it will disconnect in time.
It certainly will and does if it works on the stock OS.
Samsung messages was dropped because they didnât want to bother with development of it anymore. Itâs not like they got anything out of their own custom messaging app.
Itâs still tightly controlled by GSMA. It may now be built with openly understood components for the encryption MLS. You still have to pay for certification, licensing, access etc.
No matter what it will just not connect, setting the right permissions, setting the adb command, trying with unprivileged carrier services, nothing. Yes I know people have gad better luck but it seems Iâm unlucky.
correct, though itâs better than nothing and I was committed to putting up with it.
Absolutely false, Samsung still supports RCS, It was dropped for Verizon.
Makes sense, However it doesnât make sense when Apple, Google and Samsung have them, if it was just Google fine the argument is valid but in the end itâs a standard and technically any client can use it, But Google is not providing the necessary Developer APIs and thereâs likely a good reason for it but I digress. Itâs disingenuous to call it âNon-standardâ if itâs working for Samsung, Google and Apple
The correct wording would be, RCS is not open to developers to implement in their apps and again I have speculated in above posts.
1 Like
It actually, wasnât⌠At least they are still developing it with a big update in February 2025
Maybe they canât make up their mind.
Likely they wanted these âappsâ to create an ecosystem around Samsung in order to lock users in which were âused to thatâ. Iâve actually heard people describe âa samsung phoneâ as if it were not like every other Android handset. Their original announcement about continuing their SMS app had nothing to do with E2EE and was only about making use of Googleâs infrastructure surrounding RCS.
1 Like