microg
[BOUNTY] RCS Support [14999$]
Feature Description: Google Messages is currently the only widely available RCS client for Android. When attempting to use Google Messages with microG, users typically encounter issues such as:
A persistent message stating "RCS chats aren't available for this device." An indefinite "Setting up...", where authentication of the phone number never completes.
Recent developments suggest that Google Messages no longer strictly requires device attestation for RCS, making it possible to enable RCS functionality with microG. However, it appears there's a missing component or necessary adjustment within microG itself preventing successful setup.
Google has effectively monopolized RCS, despite it being a GSMA-backed standard intended as a successor to SMS. Unlike SMS, RCS has become a closed ecosystem under Google's control, restricting open interoperability and limiting choice for users and developers. RCS has seen significant adoption, particularly in North America, and recently Apple added support RCS, further increasing its importance as a messaging standard.
Requested Solution
Provide a solution that enables Google Messages to successfully connect to and use RCS functionality when operating with microG. Acceptable outcomes include:
- A fix or enhancement to microG itself, allowing seamless RCS connectivity.
- Compatibility with recent versions of Google Messages is desired. Solutions that only support a specific Google Messages version from the past year will be awarded half of the bounty amount.
- Modifications to AOSP or additional permissions changes are acceptable.
- The solution must work on devices with a locked bootloader.
Limitations Solutions relying on rooting, Magisk, or similar root-based tools are not acceptable.
Additional Information
GrapheneOS users, who leverage a Play services sandbox, have reported success with enabling RCS by applying permission changes. Although their setup differs from microG, the discussions that were taken in this thread (especially in the last year) may offer valuable insights for this bounty: https://discuss.grapheneos.org/d/1353-using-rcs-with-google-messages-on-grapheneos
🚀 Bounty Alert!
💰 A bounty of $5000.00 has been created by unpluggederan on BountyHub for this issue.
🔗 Claim this bounty by submitting a pull request that solves this issue!
You can also increase the amount of the bounty if you think the issue is worth more.
Good luck, and happy coding! 💻
Nice, but I would wait a bit as Google Messages started showing users with custom ROMs that they aren't secured. Let's the leaked keybox thing run its course, then we can expect some alternatives solutions. If people with regular Gapps can't get RCS, then how are we gonna get it.
Best alternative would be open API or using Apple's RCS server, just like how people used mac mini for iMessage on Android.
But I can confirm(#2063) like Huawei users that RCS push messaging works with MicorG, the issue is Play Store certification that Companion fails at. Getting Strong or going naked with no spoofing doesn't help.
$5000???????
yes I'm the founder of bountyhub and I can confirm that this has been paid in advance
$5000???????
yes I'm the founder of bountyhub and I can confirm that this has been paid in advance
Fair play. Ive just downloaded google messaging cause of this bounty and can confirm getting the same error. Since Google will slow foss rcs apps down as much as possible, GMessaging seems the only option so I hope someone can get this going!
Hi @unpluggederan Implemented RCS service with SMS permissions and TelephonyManager integration to provide the service interface Google Messages expects, enabling RCS connectivity without root access.
Looking forward for the review
Hi @unpluggederan Implemented RCS service with SMS permissions and TelephonyManager integration to provide the service interface Google Messages expects, enabling RCS connectivity without root access.
Looking forward for the review
Did you test it on a real Device with GMS core instead of google play services?
Hi @unpluggederan Implemented RCS service with SMS permissions and TelephonyManager integration to provide the service interface Google Messages expects, enabling RCS connectivity without root access.
Looking forward for the review
Very nice! Can you confirm it was tested on a real device and you can send/receive RCS messages?
@omarsoufiane @unpluggederan
This PR adds an initial RCS service implementation. It's currently a basic stub that provides the service interface structure. I'm working on improving the implementation with proper AIDL interface, comprehensive logging, and testing utilities. Will update with improvements soon.
This PR adds an initial RCS service implementation. It's currently a basic stub that provides the service interface structure. I'm working on improving the implementation with proper AIDL interface, comprehensive logging, and testing utilities. Will update with improvements soon.
Hi and good job. But does your approach confirm that Carrier Services and Play Protect certification isnt necessary for RCS instant messaging?
What about the RCS rust APK that appeared some years ago? Will IMS have a role in this or can be use Apple or the Carriers RCS servers?
@omarsoufiane @unpluggederan This PR adds an initial RCS service implementation. It's currently a basic stub that provides the service interface structure. I'm working on improving the implementation with proper AIDL interface, comprehensive logging, and testing utilities. Will update with improvements soon.
Hi and good job. But does your approach confirm that Carrier Services and Play Protect certification isnt necessary for RCS instant messaging?
What about the RCS rust APK that appeared some years ago? Will IMS have a role in this or can be use Apple or the Carriers RCS servers?
Your questions highlight that we need to move beyond the interface layer to actual RCS protocol implementation. Our current implementation is a stub that provides the RCS service interface Google Messages expects, but we haven't tested if it works without Play Protect certification, Carrier Services, or actual RCS protocol implementation (SIP/MSRP/IMS) - we need real device testing to determine what Google Messages actually requires for RCS functionality. The RCS Rust APK you mentioned could be very valuable for understanding how to implement RCS without Google's infrastructure.
@omarsoufiane @unpluggederan This PR adds an initial RCS service implementation. It's currently a basic stub that provides the service interface structure. I'm working on improving the implementation with proper AIDL interface, comprehensive logging, and testing utilities. Will update with improvements soon.
Hi and good job. But does your approach confirm that Carrier Services and Play Protect certification isnt necessary for RCS instant messaging? What about the RCS rust APK that appeared some years ago? Will IMS have a role in this or can be use Apple or the Carriers RCS servers?
Your questions highlight that we need to move beyond the interface layer to actual RCS protocol implementation. Our current implementation is a stub that provides the RCS service interface Google Messages expects, but we haven't tested if it works without Play Protect certification, Carrier Services, or actual RCS protocol implementation (SIP/MSRP/IMS) - we need real device testing to determine what Google Messages actually requires for RCS functionality. The RCS Rust APK you mentioned could be very valuable for understanding how to implement RCS without Google's infrastructure.
Recent versions of Google Messages appear to work with Jibe across all carriers (though there may be exceptions). Using a stub seems to be a good direction, as Google Messages uses GMS in the provisioning process for something. However, the purpose of other methods related to actual RCS messaging (such as connectRcs, sendRcsMessage, etc.) remains unclear and may exist purely for legacy reasons while Google Messages handles everything else
Carrier Services may or may not be required, it doesn't matter as long as RCS works, I guess someone will figure it out eventually. Based on the thread in the original post, there is a strong indication that RCS is working without device attestation (either Device Integrity or Strong Integrity) which is very good.
I don't believe the RCS Rust implementation is relevant as there is no corresponding RCS server you can connect it to. Google clearly took over RCS and now controlling the gates. Apple are allowed because it's aligned with Google's strategy. Therefore, making RCS work on Google Message is probably the only feasible way to go.
Installed your Pull Request and still getting the indefinite RCS setting up message...
Im guessing it wasnt necessary but installing the com.android.vending from the same pr fucks microG and doesnt load any google account in google messages.
also for anyone building:
edit the following from:
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.READ_SMS" />
to:
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-feature android:name="android.hardware.telephony" android:required="false" />
<uses-permission android:name="android.permission.READ_SMS" />
Hey 👋 @omarsoufiane @unpluggederan I identified that the main barrier to RCS with microG is the absence of a full IMS implementation, essential for RCS connectivity. MicroG's incomplete telephony and SMS handling also prevent activation. I have also created also created a guide that might be the solution of this..can I share it?? It's just that for some circumstances I am unable to do the test my self ..
Guide_Setting_up_an_Android_Emulator_for_microG_and_Google_Messages.pdf
So the issue is MicroG not using IMS stack Google, Samsung, Qualcomm, Huawei offers? But enabling tech like VoLTE, VoWifi, VoNR is carrier specific, not Play Services.
But it f it helps, in PixelIMS, there are some parameters in expert mode that mentions RCS. I tried them but nothing changed, its related to RCS before Jibe.
Also if RCS used IMS, sent images wouldn't use your quota for data, it would break net neutrality. For example, VoLTE in many phones use the AMR-WB bitrate to this day, you have to mod the modem for higher bitrate.
@Ankitsahami
Thank you for your input and for sharing the emulator document.
The approach outlined there is a straightforward one, but unfortunately, it does not work in practice. Anyone who has attempted to get RCS running with microG has likely already tried that method without success.
I’d also like to clarify that the GSF component is effectively obsolete. It was designed to support an old push notification API that has not been actively used by apps for over a decade. A quick review of the code confirms this. I mention it here to avoid unnecessary distractions—focusing on GSF is unlikely to help users reach a working RCS setup.
Your analysis contains some useful insights, but from what I see the document was generated by AI and therefore based on common misconceptions, especially inaccurate online information about IMS and how Google Messages operates. In reality, most carriers today do not maintain their own RCS servers and transitioning to Google. Google’s RCS implementation relies on Jibe, their RCS server that communicates directly with the device over data and authenticates it using SMS. This is why RCS can function even on carriers that don’t support RCS natively. Google's Jibe platform bypasses the carrier's IMS infrastructure entirely, however it may need to use IMS during provisioning (for example to check if the carrier has an RCS server), therefore some stub APIs might be neccessary.
VoLTE, VoWiFi, etc. are IMS based and carrier dependent, but this makes them fundamentally distinct from Google’s Jibe implementation. VoLTE and VoWiFi are handled in a different layer of the OS, Android’s telephony stack, and carrier-specific configs. Google Messages does not need to interact with these systems to enable RCS.
microG does not fully implement some key APIs that Google Messages depends on, for example phone number verification. It is possible the SMS verification is done by Google Messages too but GMS may be used to make another verification to the phone number (via SMS or system level APIs) for security reasons.
I know it's a shameless plug, but @phhusson has been saying RCS from Google isn't open and mentions Samsung older RCS implementation being closer to RCS UP. He also maintains a open source IMS stack for Exynos devices not using Qualcomm Code Aurora blobs.
Or we need a away to use Apple RCS UP in Android.
Edit: back when transferable backed-up Google Messages+SafetyNet was a thing, you didn't get encryption. So target a lover level of RCS before the current version. Or just use carriers RBM
🚀 Bounty Update!
💰 A contribution of $5000.00 has been made by malsatin on BountyHub for this issue. The total amount of the bounty is now $10000
🔗 Claim this bounty by submitting a pull request that solves this issue!
Good luck, and happy coding! 💻
And from what I understand is, RCS is closed source... mostly. I know there are some apis you can call but those had to be mainly reverse engineered and still need a bit more work. All we really need to do, is fix the bridge that is meant to contact the carrier to setup rcs.
Obviously correct me if im wrong.
And from what I understand is, RCS is closed source... mostly. I know there are some apis you can call but those had to be mainly reverse engineered and still need a bit more work. All we really need to do, is fix the bridge that is meant to contact the carrier to setup rcs.
Obviously correct me if im wrong.
Yes its closed source, Google doesn't allow 3rd party servers expect Samsung, apple, some carriers who failed to market RCS. I would say it's source available but Google wants its iMessage clone.
Some uneducated say its free for people to develop RCS thx to Google but its oxymoronic thinking. But that's just RCS buisness messaging that costs money to maintain.
GSMA ≠ Google Alphabet
@quimodotcom RCS and related specifications are open and free of charge for non-commercial use, but it could involve using proprietary (MNO (Mobile Network Operator) or Google/Apple) parts. Since I don't trust Google, I don't think it's enough to implement system services required by Google Messages, if you really care about privacy, but to also implement RCS support in some (ideally already existing) messengers, like Fossify Messages. Otherwise it could just lead to classical catch-up game with Google. I personally would rather avoid using Apple/Google infrastructure at all costs and rely only on solutions provided by MNOs. Quite a lot of them already support RCS and if not, their users need some motivation to push them to implement it...
@unpluggederan
Your link in the OP to the GrapheneOS forums redirects to https://discuss.grapheneos.org/d/3533-a-shortcut-to-quickly-open-specific-user-account. Did you mean to link to https://discuss.grapheneos.org/d/1353-using-rcs-with-google-messages-on-grapheneos?
Your link in the OP to the GrapheneOS forums redirects to https://discuss.grapheneos.org/d/3533-a-shortcut-to-quickly-open-specific-user-account. Did you mean to link to https://discuss.grapheneos.org/d/1353-using-rcs-with-google-messages-on-grapheneos?
You are right. I updated the original post. Thank you.
@quimodotcom RCS and related specifications are open and free of charge for non-commercial use, but it could involve using proprietary (MNO (Mobile Network Operator) or Google/Apple) parts. Since I don't trust Google, I don't think it's enough to implement system services required by Google Messages, if you really care about privacy, but to also implement RCS support in some (ideally already existing) messengers, like Fossify Messages. Otherwise it could just lead to classical catch-up game with Google. I personally would rather avoid using Apple/Google infrastructure at all costs and rely only on solutions provided by MNOs. Quite a lot of them already support RCS and if not, their users need some motivation to push them to implement it...
Im ngl, as much as I hate Google and their practises. If I can make sure 90% of my data is not being sent to them through microG, then I will continue to use Google apps as a frontend for microG to help me in the backend.
@quimodotcom I think you can be quite sure they will scan 100% of your messages. I don't know what could be worse. But if people are OK with sharing their passwords with them, so what. Most of the people doesn't care about privacy, because they pose no theat to the system they don't know anything about. Ignorance is bliss...
Google has effectively monopolized RCS, despite it being a GSMA-backed standard intended as a successor to SMS. Unlike SMS, RCS has become a closed ecosystem under Google's control, restricting open interoperability and limiting choice for users and developers.
While the point about Google monopolizing it is mostly true, there is some nuance here.
Google is selling RCS hosting SaaS (Jibe Cloud) to carriers. If carriers purchase this hosting service, any spec-complaint RCS client (such as Apple's iPhone SMS app, but also possibly custom clients running on Android) can connect to the RCS service provided by the carrier, but hosted by Google.
However, just for Google Messages users, Google also offers users to register even if their carrier does not support RCS. They have stated they do not wish to open access to that proprietary backend for third party apps. This would then not work on an iPhone, for example. This registration apparently requires a Firebase token, so there is integration with GMS services. They then, because they control most of the RCS servers in the world, can just integrate discovery from carrier users with their own non-carrier-supported userbase. This means that Google Messages RCS is integrated with Google, but works on all carriers. But if the carrier also hosts (or most likely, rents Google's Jibe Cloud SaaS) RCS server, Google Messages prefers that instead and notifies the user of this in the RCS settings.
This request strongly reads like a standard RCS client (that can connect to RCS everywhere where iPhones can - see list of carriers for USA, Europe) would not fulfill the acceptance criteria, but Google Messages compatibility is instead the desired outcome. Is that correct?
Hello, I'm adding a bit of information on the matter:
Doing an open-source RCS should be doable ""simply"" following the standard. It will lack encryption (at least for some time), since encryption is barely just yet part of the standard. There are already opensource RCS implementations, for example https://github.com/Hirohumi/RustyRcs [2]
Now, with regards to the Play Integrity situation, and (relatedly) carrier situation: Basically, Google Messages, is both a RCS client, and a client to Google's proprietary messaging network. If you're on a true RCS network, then you don't have a Play Integrity issue. If you are on Google's proprietary messaging network, then you do. Google Messages acts as a RCS client when your operator supports RCS [1], and goes to Google's proprietary network otherwise.
But anyway, if RCS works on iOS on your carrier, it should be workable with an open-source RCS client, otherwise it's unlikely.
[1] FWIW the definition of "support" is really murky. There are official standard ways to declare a RCS server, but not everyone uses it, and you might end up connecting to an address that weirdly looks like Google's proprietary network
[2] Don't be fooled by the fact that it's an Android app. It's basically not connected to Android except for the build system. There is a lot of plumbing to make before it's usable
so it can help.
It is not able to retrieve the rcs config, your phone number or anything from your carrier or carrier services. At least thats what it seems to be struggling on