GrapheneOS
Google Messages Fails to obtain Privileged permissions required for IMS registration despite Bugle being able to READ_DEVICE_IDENTIFIERS. Google Messages is unable to read device identifiers in SubscriptionManager.
Google Messages requires the android permissions READ_PRECISE_PHONE_STATE, READ_, PRIVILEGED_PHONE_STATE, READ_PHONE_NUMBERS CONNECTIVITY_USE_RESTRICTED_NETWORKS and PERFORM_IMS_SINGLE_REGISTRATION, all are for RCS to function and for IMS Provisioning. (See https://source.android.com/docs/core/connect/ims-single-registration)
On the stockOS, Google messages obtains all these permissions when Google play services and Google messages are given the phone permission and Google Messages is set as the default SMS application. Shortly after, verification begins, and auto verification gets enabled in your Google account alongside better sharing with google.
Now that device identifiers can be read by bugle and the droidguard fix was implemented (see below) by enabling the phone permission to Google play services, the expected behavior would be for Google messages for obtain the above permissions. This causes google to verify your phone number but fails repeatedly to connect due to these missing required permissions.
Google play services has the following permissions when this error occurs: network, phone, sensors, SMS, contacts, phone, unrestricted battery and mobile data, and DCL via memory and storage set to allow.
Google settings show phone number is verified and better sharing with Google is enabled. Google meet works perfectly fine, which is worth noting. Can make E2EE calls.
Google messages has the following permissions( I've tried several variations): Network, phone, sensors, sms unrestricted battery and mobile data, Alarms and reminders, display over other apps, DCL via memory and storage ( Phone number verification fails if DCL via memory is restricted). I tried give it all the permissions and the issue persists.
Privileged permissions for Google Messages are needed for certain specific carriers in the US but not in general.
Thanks for the reply @thestinger . Interesting, I'm not in the US. Based on these logs, do these imply that my carrier requires these permissions for Google messages to provision RCS? And when you say certain carriers, is this for carrier using CBRS, as in Private 5G/LTE? Starting to think there's a issue on the carrier side or with my phone number or eSIM.
Some carriers require these privileged permissions for Google Messages, but most currently don't. Older versions of Google Messages do not require it for those carriers, so people have had success using older versions. However, if you update, it will stop working after a while and cut off access. We don't recommend staying on an old app version that's going to end up being missing security patches and may already be missing them.
The privileged permissions seems to be required for Google Messages for carriers using a newer RCS approach where the carrier is responsible for more of it than before. Google has been gradually shifting RCS away from being a centralized Google service to being a carrier provided service, but that's far from done. It's still always at least partly a Google service and many carriers also delegate hosting it to Google too.
Thanks again for the reply. Okay so they're shifting away from Jibe by the sounds of it. It was only a matter of time. RCS is a bit of a mess to say the least, so I'm sure getting it to work on Graphene is not an easy task, especially when there's so many issues even for people running stock.
Appreciate the work you've been doing on this project btw @thestinger , incredible work!
@afor3m3nti0n3D Is there a reason for closing it? We do plan to provide a way to use this for carriers needing it.
Okay that is great news. It's been reopened. Thanks for the nudge to reopen it! @thestinger
I'll add to this. Perhaps it might be helpful.
Based on some testing I don't think carrier services is required anymore for most carriers. It used to be for my carrier, but has no use whatsoever now. In fact, when you install the BETA version CarrierServices-carrierservices.android_20250826_00_RC00.phone , it gets installed in a disabled state. This behavior is present on the Stock OS and Samsung OneUI 8 running A16, so this behavior seems to be related to Carrier Services in itself. I force enabled it using adb shell pm enable com.google.android.ims. The one thing interestingly that got it running without force (forcing it to start with am start or broadcast) was adding an IMS and CBS string to my APN settings. These were the default strings prior to changing to GrapheneOS: default,dun,supl,mms,xcap,hipri,ims,cbs
Eventually it just started and produced cache and app data.
I thought I'd include some logs seen below when carrier services started running after altering the APN settings.
Some carriers require these privileged permissions for Google Messages, but most currently don't. Older versions of Google Messages do not require it for those carriers, so people have had success using older versions. However, if you update, it will stop working after a while and cut off access. We don't recommend staying on an old app version that's going to end up being missing security patches and may already be missing them.
It seems from the discussion of this issue on the Graphene forums, that it may not be clear to the devs that for many users on carriers that have the issue, like T-Mobile, using an older version of Messages is not sufficient to get RCS working. You have to install an older version to get RCS to verify and show as connected. But then you have to upgrade to the Play Store version to get it to connect to Etouffee (show as "true" in the Messages debug menu). But as you note, this means that after a while (usually 36 hours) access is cut off and one has to repeat the process. For these users, they have to repeat this process every 36 hours to keep RCS working. The GrapheneOS account on the forums suggested that users on affected carriers could use an old version to get RCS working, but that is not true for many people.
Another problem that leaves these users in a difficult position is that if they turn off RCS, group chats do not fall back to MMS (in the way that individual threads fall back to SMS). It seems that to get group chats to work as MMS, every person on the chat has to delete it on their phone and then a new MMS chat has to be created. This is also true if you leave off RCS long enough that you are automatically removed from the groups. You will not be able to be added back to the groups once RCS starts working again. In addition, if a new group chat is created via MMS without all users deleting the old chat, it will not work. Requests to delete the existing group chat is not feasible for large group chats with many non-technical users who are not going to be patient with requests from GrapheneOS users to delete the chat (plus some people want to keep the old messags). The end results is that if a GrapheneOS user was using RCS, before it broke at the beginning of September, they either have to disable RCS and abandon all of their group chats with no clear hope of being able to recreate them in the future, or, for certain users, go through the hassle of reinstalling an old version of Messages and upgrading to the Play Store version every 36 hours.
I say this only to point out that the problems with RCS effectively breaks existing group chats, with no feasible way to receate them as MMS group chats. Hence the problems with RCS breaks basic messaging functionality, beyond RCS itself. For users in this position, I see the lack of a solution as serious bug and not just a feature request that would be nice to have.
@cb474 You're correct that the old APK from ~December 2024, being installed does not resolve the issue for most people. I'm quite sure the reason it works for some, is that that version of the app appears to be able to bring up SIM CARD messages, and allows the android permission READ_MESSAGES_ON_ICC. I suspect this somehow tricks SubscriptionManager, only temporarily. The old version doesn't display wireless emergency alerts in the settings page, while the later versions have this built in. I created a separate bug report of not being able to launch Wireless Emergency alerts from Google Messages too (OS Tracker issue #6330, just before this report). There's numerous errors with Google Messages not being able to find CellBroadCastReceiver, and these errors logs seem to not be present with the old APK as it isn't looking for CellBroadCastReceiver. In terms of the RCS group chats, that issue you mention is expected behavior; if RCS functionality breaks for one reason or another (i.e. Carrier related issues), you'll be unable to fallback to sending MMS group chats, even if the other users are using iPhone using RCS, which doesn't use encryption like Android does. So that is expected behavior when RCS is unable to fallback to MMS if all other users, including iPhone users, have RCS enabled. In other words, this issue isn't specific to GrapheneOS and it has happened me even running OneUi or Stock Pixel OS. It is rather annoying though. But that's a Google Problem. The issue that @thestinger is working on hopefully in the near future, would allow Google messages to obtain the permissions seen below, as these are considered privileged permissions that the default messaging app expects to have and The default messaging app expects to be the only SMS app on the device, upon first boot.
Essentially, Google Messages needs to be deceived into thinking it was the default messaging app, which is why permissions need to be assigned to it before it is first launched, for those who can currently get it working. If those conditions aren't met, all these permissions aren't granted therefore revoked and SubscriptionManager returns a null value and carrier privileges aren't granted and IMS Single Registration fails. Most carriers don't use this model, especially MVNOs, because they don't own the infrastructure and piggyback off of it, for lack of a better term. It's very few carriers that do this, but the ones that do, have millions of customers.
One thing to note for as well for those following this issue, if you don't enable DCL via Memory first, before granting any other standard permissions THEN enable the special permissions "Allow Alarms and Reminders", Google Messages will fail to obtain this permission as well, and that special permission won't be able to granted or even viewed in the permissions page, nor will you see in the Messages app itself "If you enable alarms and reminders then enable "Unrestricted Battery", this for some reason also prevents this permission from working, as it appears granting alarms and reminder automatically grants unrestricted battery by default for messaging apps. I've done extensive testing with this. This issue can easily be reproduced in case anyone wishes to test it. Seems this also applies to WhatsApp as well and any app that relies on alarms on reminders (Standard Notes, Google Maps). For some reason this needs to be granted prior to any other permissions or it simply does not show up as a special permission
@afor3m3nti0n3D Thanks for the detailed information. I appreciate it.
I thought I read elsewhere that the model T-Mobile is using is what Google is pushing carriers to do and that eventually this problem will probably affect more people on more different carriers. Do you know if that's correct?
Regarding the issue of group chats. Why is it that individual chats fall back to SMS okay, even if the other party continues to have RCS enabled, but not group chats? And do you know why you can't just disable RCS, create a new MMS group chat with the same people and have that work (in my experience the other people don't get the messages in the new MMS chat)? Do you have any idea if Google plans to fix this?
Thanks again.
@cb474 You're welcome. Yes that is correct that other carriers will eventually be following suit and following this model. It's complicated, but using a Single IMS registration model will be the standard, as it reduces network traffic. The IMS dual registration will eventually become deprecated as it is only in theory supported up to Android 11. Most carriers haven't implemented it yet because of cost constraints, as it requires significant changes to their infrastructure. I would recommend reading this: https://source.android.com/docs/core/connect/ims-single-registration
You'll see that under this model, carrier can deny "carrier privileges" (in essence= no RCS) if the default messaging app is found to not meet all the requirements.
The reason you can use SMS as a fallback to RCS for one-on-one conversartions, is because this feature was directly added in Google messages as a fallback or failsafe. The reason you can't fall back to SMS in a group chat when it is an RCS group chat is because RCS is over the internet and uses port number 443 on Google devices, and port 80 on Samsung devices. The fallback of MMS is not possible because it would fail to be routed through your carriers MMSC server which usually uses a specific proxy port set by the carrier. The MMSC is what you would see under your APN settings in your phone. If its an RCS group it will use use the ACS/PCSCF of the RCS server used by your carrier ( what allows the messages to be E2EE) so fallback is not possible.
In terms of disabling RCS and recreating an MMS group, all parties would need to leave the group and the person whom created the group would, would need to delete the group as a last step, then set up the MMS group afterword. RCS is entirely different then Multi Media messaging in terms of how it is routed over the carrier network, same with SMS. You would have to send it as a mass SMS (individual reply to all recipients) instead of a group MMS, in order for SMS fallback to work in that scenario. This isn't something that can really be fixed and it's a shortcoming of this fiasco we have where SMS and MMS still exists concurrently with RCS. The only real solution is to phase out SMS and MMS entirely which is what GSMA, 3GPP, Google and carriers are/have been trying to achieve, albeit, slowly and poorly in my opinion.
@afor3m3nti0n3D Thanks. That was a very helpful explanation for things that I have noticed to be true in practice, but really did not understand why.
So DCLM for Play Services is required 100% for RCS to function whether carriers are using the non-privileged approach or the privileged one?
@pingu-the-penguin the only way I was ever able to get it working n the past. Seems to cause issues reading the SIM subscriber information if you don't allow. I've had it crash with a DCL via memory error and I've seen "device not supported/ RCS is not available for this device" or "Rcs is disabled by your carrier" if it is set to deny. Play services also requires it set to allow for it to function.
Enabling Alarms was the key to getting the "every 36 hour reinstall" process to start working for me again (guessing one of the recent GOS updates changed something). Thanks for all this context and info I really appreciate it.
My RCS process notes
- Uninstall messages
- Install 2024 apk using android-tools over usb debugging
- settings -> apps -> messages a. sms -> default app b. alarms -> enable
- open messages [this is the first time it is launched]
- dismiss all the normal startup notifications of messages
- see message that RCS is enabled
- Update via play store
@tebriel Glad I could help. I thought this might be something that could easily go unnoticed or overlooked.
@pingu-the-penguin yes that is right, play services needs it and based on testing messages seems to need it as well. Without DCL via memory for Messages enabled, it will not allow you to enable the Alarms and reminders special permission and the notification reminders permission in Google Messages will not be present under Message Settings>General>Notifications Reminder Behavior '1 Hour Action. Seems to cause issue with RCS too whereby it will say SIM unsupported or RCS is not available for this device.
@tebriel Glad I could help. I thought this might be something that could easily go unnoticed or overlooked.
As of today the method seems to not work anymore. I'm on GOS 2025102801. I'm stuck on 'trying to verify'.
From reading the IMS Single Registration notes, and the comments above, it sounds like IMS Single Registration can be expected to be phased in by carriers regardless of RCS, the mandate for them to take over thr RCS support is just what's lighting a fire for them to actually finally do it. Which means phone call access may also require it eventually too.
It sounds like the limitation on GOS currently is that the System service that acts as the single register-er mandates apps that access it meet three limitations: 1) they have the new(ish) IMS_SINGLE_REGISTRATION permission, 2) they have the existing READ_DEVICE_IDENTIFIERS permission, and 3) they are a System app.
The READ_DEVICE_IDENTIFIERS seems like a reasonable requirement for talking to a carrier to authenticate and handshake services and is already addressed by GOS by granting it automatically under certain appropriate conditions.
The IMS_SINGLE_REGISTRATION doesn't seem like there's really any reason to differentiate it from the "SMS services that cost you money" permission that already exists. From a threat perspective you're already granting direct access to carrier-related services with that. The threat surface does increase some from being able to talk to a System daemon's API.
The "must be a System app" seems a lot more lock a vendor lock-in thing than a security benefit. It minorly mitigates possible on-device abuse of the API, butthat doesnt really reduce the risk since the primary threat seems like it would be via compromise of whatever RCS or phone app is in the System, which could very well be a very out of date version. From a vendor lock-in perspective though, it's a great yool to guaratnee which app (singular) you're allowed to use for RCS, and may eventually also dictate the dialer app.
There's mention above that it sounds like both Google Play and the actual RCS app would need to these permissions. Logically to me, tying the IMS_SINGLE_REGISTRATION permission to the same conditions for READ_DEVICE_IDENTIFIERS for both Google Play and the SMS app would make sense. The only remaining question is the "system app" requirement. Obviously that's not going to happen, which suggests to me that the enforcer of that permission requirement will have to be modified. Im presuming that's the bulk of the difficulty in this implementation.
@mtalexan Ugh, I find it a little terrifying that just being able to use the dialer and therefore being able to place normal phone calls could fail, due to these chanages. I still don't understand why this issue is labled a feature request and not a high priority bug. It seems to me that a phone operating system, being able to function with basic underlying functionality of the carrier system (sending carrier based messages, placing phone calls) is about as fundamental as you can get in terms of functionality of a phone OS. If it's broken (RCS) or may soon be broken (dialer), that seems like a major bug to me.
In any case, thanks for the detailed explanation of the various underlying issues causing this problem.
@cb474 Google Messages is a proprietary app with a proprietary messaging system tied to Google services. This issue has nothing to do with standard messaging and phone call functionality but rather Google Messages not having privileged integration into the OS required for some of the functionality. This issue is not about any OS functionality not working as expected and is certainly not a bug. Not giving privileged access to Google Messages is not somehow a bug.
@cb474 I'm certainly not an expert on this, I'm just going from what I read in the linked description, what I've read about Android permissions architecture, and some years of unrelated software development experience.
Phone and SMS/MMS were listed as examples of existing services that can be combined in the Single Registration solution, but it's up to the carrier what they require/allow. They're not going to drop Multi Registration any time soon since all devices would have to be updated to a new enough version they support the (relatively new) Single Registration or lose all services. But the carriers are incentivized to move to Single Registration since it (eventually) greatly simplifies parts of thier networking stack, and saves them money (immediately) in their infrastructure by reducing the number of device registration messages.
However, carriers may force use of only one of the two Registration types from a single device and prohibit mixing. There are both technical design reasons this might happen, as well as pragmatic ones. If that's the case for a carrier and GOS adds support for Single Registration to support RCS (required for RCS, though some carrier still have some partial Multi Registration support for RCS that allows the current known work arounds), it might cause all other carrier services to stop working as well when the legacy Multi Registration is used for this older services.
Just addressing Daniel's point too:
This is a new OS feature (IMS_SINGLE_REGISTRATION) being required for a new carrier feature (RCS) that currently is only even available on OEM Android devices using a single proprietary app (Google Messages) when it has maliciously invasive integration requirements met. No existing device functionality is being lost or blocked by GOS in any way, so it's not a bug.
It's a new requirement from some Carriers that they will only support the new RCS service if you use the new OS feature to communicate with them. But as the current workarounds demonstrate, there is still partial support from many carriers for the new RCS feature even without this new protocol/OS feature beig used.
Android seems to encourages full migration of all carrier services to use this new OS feature, but it's highly probable that some/many/most(?) carriers don't even support existing features (Phone, SMS/MMS) using it yet, and certainly won't require it for many years.
@thestinger Thanks for the reply. I take your point about Google Messages being proprietary and requiring permissions that GrapheneOS objects to. I understand this is the source of the problem.
But I don't think there really is a cut and dried, black and white, answer to this. Since RCS is intended to be the replacement for SMS as carrier based messanging, any phone operating system that doesn't support it is and/or will not really be functional in a very basic way. If this requires using a proprietary app like Google Messages, then there is no ideal solution. But I don't think that means broken RCS is a viable option.
Already RCS is causing headaches for people who were using RCS, until the recent changes broke it and with group messages can't fall back to MMS. The only solution is to get everyone in a group message to delete the thread and then create a new group thread. For anyone with a lot of large group threads, this is practically infeasible. Other members of the thread are often not willing to do it. Now these GrapheneOS users can't even use existing group threads through MMS, regardless of which SMS messaging app they use. To me, that seems like a bug.
Unfortunately, as an end result of these group thread problems, I've seen many users say they can no longer use GrapheneOS.
If the same problems were to happen with dialer apps requiring the same privileged permissions and one could no longer make phone calls, that to me would seem to be a bug as well.
Unfortunately, as long as Google and Apple have special relationships with the carriers that let them dictate how basic elements of carrier based messaging and phone calls work, people are kind of stuck with these proprietary realities. At some point, for such basic phone functionality as carrier based messaging and phone calls, to me it seems the difference between a bug and a feature isn't a very meaningful distinction anymore, if basic things just stop working.
Anyway, that's how I view it. Thank you for all your work on GrapheneOS.
@cb474 Well put. It's a touchy subject. I can see why @thestinger is leaving this as a feature request, as almost all grapheneOS users would deem this to be an anti-feature especially if it isn't required by their carrier of choice and they have RCS working without the additional privileged permissions. The reality is that the largest carrier in Canada does use this registration model, Bell Mobility. Rogers, Telus and MVNOs do not currently, but they will. I can't speak on American Carriers. It's not if, but when the other carriers will follow suit..With Google, GSMA and 3GPP monopolizing and forcing Google Messages and Samsung messages (which even now, when you use it, it tells you to switch to Google messages as it's being deprecated and iPhones messaging app, which doesn't support E2EE) to be one and only app capable of accessing these permissions, is good example of Googles sway in the industry. They prevented any means of 3rd party app developers or OS developers like Graphene to create an SMS app with RCS integration, as it would be considered copyright infringement, among other things. Would I like to see this as an option that can be toggled in the OS eventually -- yes. Is it causing a lot of people to return to stock OS? --Yes. IMO, a majority of users started using for GrapheneOS for the wrong reasons, to "Degoogle". In reality, everyone should want to use GOS it as it gives you more control over your device and a significant amount of security benefits and privacy benefits. Privacy is harder and harder to achieve in this climate, and attacks only get more sophisticated by the day. I'll take a more secure OS with a slight privacy reduction any day ( i.e. : Using SMS vs. RCS). RCS can still be intercepted if one is motivated enough to do so, and it isn't a golden ticket. But it most certainly is annoying for group chats, but IMO, if people really cared about privacy, they'd be using Signal for those chats. Still blows my mind that not everyone uses Signal, but as I'm sure you've experienced getting people to change to it is easier said than done. #rantover
They prevented any means of 3rd party app developers or OS developers like Graphene to create an SMS app with RCS integration, as it would be considered copyright infringement, among other things.
What's your basis for claiming others can't make an RCS app? Others not doing it in practice doesn't mean they can't.
Is it causing a lot of people to return to stock OS?
Our userbase is substantially growing, not shrinking. What's your basis for claiming this?
I'll take a more secure OS with a slight privacy reduction any day ( i.e. : Using SMS vs. RCS). RCS can still be intercepted if one is motivated enough to do so, and it isn't a golden ticket.
RCS is only more private than SMS if Google Messages is being used at both ends with the Google Messages end-to-end encryption protocol. RCS between Android and iOS does not provide privacy advantages over SMS since it currently lacks end-to-end encryption. Apple has said they'll add it eventually, but via the standard MLS protocol rather than the one Google Messages has been using. Google Messages is in the process of moving to the standard MLS but iOS doesn't have it. You're essentially just saying using Google Messages at both ends is more private than using SMS without it, but using Signal or many other options is more private than Google Messages.
I'll take a more secure OS with a slight privacy reduction any day ( i.e. : Using SMS vs. RCS).
Yes, I would accept that as well. The problem is that this is not an option for people who started using RCS a year ago, when it was working without all the current restrictions of Google Messages, because of the way that RCS has broken group messages. As I explained above, you can't just fall back to MMS, unless you can get all members of a group chat to delete the chat and then create a new one (it even seems that the new group message must be created by an Android user and not on an iPhone). Since it is often practically infeasible to get everyone to go along, this means that if you disable RCS you cannot for all practical purposes have a group message with any particular group of people where an existing group message had been operating via RCS.
The end result for this group of Graphene users is that basic MMS group messaging is effectively broken on their device. Completely getting rid of Google Messages will not solve the problem. The only practical solution is to keep using Google Messages and use one of the old versions of Messages as a workaround (a solution that could stop working at any moment).
This is why, from my perspective, somewhere in the grey area, between Google Messages and GrapheneOS a bug exists. It is not a Graphene bug, because the problem could not happen without having a some point enabled RCS in Google Messages. But it is also not a bug in Google Messages, because the problem would not exist on stock Android. But in the space where the two exist together, even temporarily, carrier based group messaging gets broken on GrapheneOS, with no way to go back to how things were before one first enabled RCS with Google Messages.
**
RCS is only more private than SMS if Google Messages is being used at both ends with the Google Messages end-to-end encryption protocol. RCS between Android and iOS does not provide privacy advantages over SMS since it currently lacks end-to-end encryption. Apple has said they'll add it eventually, but via the standard MLS protocol rather than the one Google Messages has been using. Google Messages is in the process of moving to the standard MLS but iOS doesn't have it. You're essentially just saying using Google Messages at both ends is more private than using SMS without it, but using Signal or many other options is more private than Google Messages.
Even without end-to-end encryption, isn't RCS still more secure and private? I'm honestly asking. I thought it still has encryption in transport. And it is not subject to some of the known unfixable bugs in SMS, that led the U.S. government to warn people that they should assume their SMS messages are being monitored by foreign governments. I thought RCS, even without E2EE, was still a huge improvement over this.