search

GrapheneOS / os-issue-tracker

Issue tracker for GrapheneOS Android Open Source Project hardening work. Standalone projects like Auditor, AttestationServer and hardened_malloc have their own dedicated trackers.
https://grapheneos.org/
336 stars 18 forks source link

Cannot Access T-Mobile Visual Voicemail on AOSP and Google Dialers #1951

Open theuser18 opened 1 year ago

theuser18 commented 1 year ago

My Pixel 7 on T-Mobile (newest Graphene version installed) on both Google Dialer and stock with GPS installed prior to installing. Below are my carrier settings and APN info. This has been a problem since I initially installed it. I get the error "Can't update visual voicemail." I have tried resetting carrier settings.

Carrier Settings: tmobile_us-42000000023.10

APN: fast.tmobile.com

211423415-a7b51675-61f4-4bc7-9af0-c1c8cac5a1e6

girlbossceo commented 1 year ago

Is this still an issue? No one else has reported this bug. Have you followed https://grapheneos.org/usage#carrier-functionality ?

spammerofspam commented 1 year ago

I've got the same issue on my Pixel 7 on T-Mobile USA. The only way I've found to get visual voicemail is by using the T-Mobile Visual Voicemail app. On both the Graphene dialer and the Google dialer, I have the same problem as reported here.

Has anyone gotten this to work on the Pixel 7 on T-Mobile? There are some discussions on Reddit and the Graphene forums about it, and all the replies of "it works for me" seem to be either on other Pixel devices (e.g., 6a or 4a) or on other carriers.

Also, this phone was purchased new by me and I immediately put Graphene on it. It never connected to T-Mobile while running the stock OS. Is it possible that has something to do with it? Is there some sort of activation process that the standard Android release would've done the first time it connected that wasn't done on Graphene?

Edit: I compared my Access Point settings with a Pixel 6 on the same plan. That Pixel 6 is running stock firmware and has working Visual Voicemail. The Access Point settings all matched between the two. The carrier settings version differs between the two, though.

texzag commented 1 year ago

I have a Pixel 7 pro on Spectrum mobile (Verizon network). I too am not able to get any indication of voicemails or visual voicemails. I've reset network settings and even went as far as getting a new sim and having Spectrum reset my voicemail..no luck. Any updates on this issue at all?

theuser18 commented 1 year ago

Is this still an issue? No one else has reported this bug. Have you followed https://grapheneos.org/usage#carrier-functionality ?

I have seen that link and yes I am still having problems

girlbossceo commented 1 year ago

@theuser18 @texzag @spammerofspam Please provide your carrier settings version from Settings -> Network and Internet -> SIMs -> Operator settings version

spammerofspam commented 1 year ago

@theuser18 @texzag @spammerofspam Please provide your carrier settings version from Settings -> Network and Internet -> SIMs -> Operator settings version

Mine is tmobile_us-43000000026.12

texzag commented 1 year ago

@r3g-5z Spectrum_us-43000000011.12 2022-12-08

girlbossceo commented 1 year ago

Could you show me your MCC and MNC id in APN settings as well?

texzag commented 1 year ago

@r3g-5z

MCC 311 MNC 480

spammerofspam commented 1 year ago

Could you show me your MCC and MNC id in APN settings as well?

tmobile_us-43000000026.12

MCC: 310 MNC: 260

(Same MCC / MNC as in original screenshot)

theuser18 commented 1 year ago

Visual voicemail still does not work even after the new update.

texzag commented 1 year ago

Still not working with Spectrum mobile either.

exalented commented 1 year ago

Not working for Mint Mobile either ultra_us-44000000001 MCC: 310 MNC: 240 MVNO: gid: 756D 2023-03-30

Working by switching to Verizon MVNO USMobile: verizon_us-44000000015 MCC: 311 MNC: 480 2023-03-24

meichthys commented 1 year ago

Also not working on my t-mobile pixel 7 Settings: tmobile_us-43000000026.12 MCC:310 MNC:260

lanerussell commented 1 year ago

Seeing the same behaviour. I see a notification that I have a voicemail, but Phone app shows "Can't activate visual voicemail".

Pixel 7 T-Mobile USA Release: TQ2A.230505.002.2023051600 Settings: tmobile_us-43000000026.12 MCC: 310 MNC: 260

theuser18 commented 1 year ago

This seems like a pretty widespread issue. Has anyone heard if any project members have their eye on this problem?

charltonstanley commented 11 months ago

I'm also experiencing this issue on T-Mobile. I live in the USA and my phone was purchased from google.

TQ3A.230705.001.2023072600
tmobile_us-44000000029
MCC: 310 MNC: 260
2023-04-14
seniorm0ment commented 9 months ago

Having issues as well, on both my lines. I activate visual voicemail in Google Phone's settings. It seems to say it's activated. I then receive a voicemail, it cannot play it back, nor load any transcription. Play Services has Phone, Call Logs, and Network permissions. Same with Google Phone app.

Pixel 6 Pro (Unlocked), T-Mobile for Service GrapheneOS:Version: 2023100300 Dual-Sim (Physical and eSim)

tmobile_us-44000000149 MCC: 310 MNC: 260 2023-04-14

tmobile_us-44000000149 MCC: 310 MNC: 260 2023-04-14

Slyfox88 commented 7 months ago

I have the same issue on multiple carriers that use the T-Mobile network. The T-Mobile Visual Voicemail app and My Visual Voicemail app works fine, but not the built-in phone voicemail app. I had the same issue on LineageOS, so the issue appears to be with the default AOSP phone app. Doesn't anyone know where you can report a bug for that app, as this issue has persisted for at least a year. Most people would just say F--- it and get an IPhone after that long with it still not being fixed.

uncon commented 6 months ago

I have this same issue on my Pixel 7 Pro (fresh GrapheneOS installation) with T-Mobile on both AOSP and Google phone apps.

tmobile_us-52000000017
MCC: 310 MNC: 260
2023-09-27
thestinger commented 6 months ago

Some US carriers require carrier apps we aren't including.

uncon commented 6 months ago

Some US carriers require carrier apps we aren't including.

I'm not saying you are wrong about this requirement, but this VVM integration works fine on the stock Pixel firmware on my phone (purchased from Google) without any (visable) carrier apps.

kinghat commented 6 months ago

Not working for Mint Mobile either ultra_us-44000000001 MCC: 310 MNC: 240 MVNO: gid: 756D 2023-03-30

also not working on mint for me with same apn settings.

I have the same issue on multiple carriers that use the T-Mobile network. The T-Mobile Visual Voicemail app and My Visual Voicemail app works fine, but not the built-in phone voicemail app. I had the same issue on LineageOS, so the issue appears to be with the default AOSP phone app. Doesn't anyone know where you can report a bug for that app, as this issue has persisted for at least a year. Most people would just say F--- it and get an IPhone after that long with it still not being fixed.

"My Visual Voicemail" app works fine as well. though, the google phone apps builtin visual voice mail worked as expected for me on LOS :man_shrugging:

TheMCNerd2017 commented 5 months ago

I'm having the same issue with a new Pixel 8 Pro using the same T-Mobile SIM card that I had in my Pixel 4 XL (which was able to use Visual Voicemail in the AOSP dialer without any issues up until the day I powered it down and removed the SIM card). I did notice that upon inserting the SIM into the 8 Pro after removing it from the 4 XL I got an automated T-Mobile SMS message stating "There's a new version of the Visual Voicemail app available now." along with what I presume is a download link to said application.

I'm guessing T-Mobile is now forcing a specific application and is blocking new devices from accessing Visual Voicemail with the AOSP Dialer?

thestinger commented 4 months ago

Is this resolved on the latest release?

meichthys commented 4 months ago

It doesn't seem to be working for me on build: UQ1A.240205.002.2024020500 T-Mobile pixel 7

theuser18 commented 4 months ago

It is not resolved for me. Pixel 7 TMobile on the latest stable release build UQ1A.240205.002.2024020500.

-------- Original Message -------- On Feb 8, 2024, 10:53 PM, Daniel Micay - notifications at github.com wrote:

Is this resolved on the latest release? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID:

DuckDuckGo removed one tracker. More

Report Spam

Is this resolved on the latest release?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

kinghat commented 4 months ago

Not working for Mint Mobile either ultra_us-44000000001 MCC: 310 MNC: 240 MVNO: gid: 756D 2023-03-30

also not working on mint for me with same apn settings.

I have the same issue on multiple carriers that use the T-Mobile network. The T-Mobile Visual Voicemail app and My Visual Voicemail app works fine, but not the built-in phone voicemail app. I had the same issue on LineageOS, so the issue appears to be with the default AOSP phone app. Doesn't anyone know where you can report a bug for that app, as this issue has persisted for at least a year. Most people would just say F--- it and get an IPhone after that long with it still not being fixed.

"My Visual Voicemail" app works fine as well. though, the google phone apps builtin visual voice mail worked as expected for me on LOS 🤷‍♂️

im not sure what changed or when but my visual voicemail in googles phone app is working now. still on mint mobile :man_shrugging:

chenxiaolong commented 2 months ago

I've been trying to troubleshoot this for my setup (Pixel 8 Pro with T-Mobile USA postpaid plan).

I modified LegacyModeSmsHandler in GrapheneOS' dialer app to log the messages sent for VVM activation.

When sending either the CVVM Activate:dt=6 or Deactivate:dt=6 messages to 122 (T-Mobile's VVM destination number), T-Mobile returns the SUBSCRIBER_BLOCKED status:

2024-04-18 20:34:59.240514 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - eventType=STATUS, data=Bundle[mParcelledData.dataSize=128]
2024-04-18 20:34:59.240779 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=rc, value=0
2024-04-18 20:34:59.240981 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=st, value=B
2024-04-18 20:34:59.241160 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=srv, value=vvm.mstore.msg.t-mobile.com

However, if I send the CVVM STATUS:dt=6 message, T-Mobile returns the SUBSCRIBER_READY status with the IMAP credentials for accessing the voicemails:

2024-04-18 20:35:32.752798 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - eventType=STATUS, data=Bundle[mParcelledData.dataSize=388]
2024-04-18 20:35:32.753213 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=pw_len, value=4-9
2024-04-18 20:35:32.753472 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=vs_len, value=10
2024-04-18 20:35:32.753724 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=u, value=<redacted>
2024-04-18 20:35:32.753925 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=pw, value=redacted>
2024-04-18 20:35:32.754137 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=rc, value=0
2024-04-18 20:35:32.754357 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=st, value=R
2024-04-18 20:35:32.754565 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=ipt, value=148
2024-04-18 20:35:32.754742 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=srv, value=e7.vvm.mstore.msg.t-mobile.com
2024-04-18 20:35:32.754971 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=lang, value=1|2|3|4
2024-04-18 20:35:32.755164 -0400 E/Dialer  ( 3615): LegacyModeSmsHandler - data: key=g_len, value=180

I manually tested the IMAP credentials with curl and confirmed that they are valid:

❯ curl -v imaps://<redacted>:<redacted>@e7.vvm.mstore.msg.t-mobile.com/
<...>
* Connected to e7.vvm.mstore.msg.t-mobile.com (2607:fb90:c13f:10b::4) port 993
<...>
*  subject: C=US; ST=Washington; L=Bellevue; O=T-Mobile USA, Inc.; CN=vvm.mstore.msg.t-mobile.com
< * OK [CAPABILITY AUTH=DIGEST-MD5 IMAP4rev1 QUOTA UIDPLUS] mStore IMAP4rev1 Server is ready.
> A001 CAPABILITY
< * CAPABILITY AUTH=DIGEST-MD5 IMAP4rev1 QUOTA UIDPLUS
< A001 OK CAPABILITY completed.
> A002 AUTHENTICATE DIGEST-MD5
<...>
< A002 OK login successful
> A003 LIST "" *
< * LIST (\HasNoChildren) "/" "/INBOX"
* LIST (\HasNoChildren) "/" "/INBOX"
< * LIST (\HasNoChildren) "/" "/Greetings"
* LIST (\HasNoChildren) "/" "/Greetings"
< * LIST (\HasNoChildren) "/" "/Trash"
* LIST (\HasNoChildren) "/" "/Trash"
< A003 OK LIST completed.
* Connection #0 to host e7.vvm.mstore.msg.t-mobile.com left intact

If I hack the dialer to send the status CVVM message instead of the activate message, then it successfully persists the credentials and visual voicemail works.

I'm not sure why activation fails on GrapheneOS yet. It seems to work on the stock Pixel OS. The one weird thing I noticed is that when I'm running GrapheneOS, T-Mobile's website reports the device as being a "Galaxy Note9 - Ocean Blue - 512GB". When I'm running the stock Pixel OS, T-Mobile's website correctly reports the device as being a "Pixel 8 Pro - Obsidian". I wonder if this is why T-Mobile is blocking the activation and deactivation messages.

Unfortunately, I'm not super familiar with the telephony stack yet and have no idea how T-Mobile is determining the model. Maybe things will just work if it detects the correct model.

meichthys commented 2 months ago

@chenxiaolong great work! Hopefully this will help pinpoint the actual issue 👍

chenxiaolong commented 2 months ago

For folks building GrapheneOS from source, this is the little hack/workaround I applied to allow visual voicemail to work on T-Mobile USA. It's definitely not a proper fix, but it seems to work well enough.

# Apply in packages/apps/Dialer/
diff --git a/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java b/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java
index 0df639fcb..4124d5b15 100644
--- a/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java
+++ b/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java
@@ -33,7 +33,7 @@ public class OmtpCvvmMessageSender extends OmtpMessageSender {

   @Override
   public void requestVvmActivation(@Nullable PendingIntent sentIntent) {
-    sendCvvmMessage(OmtpConstants.ACTIVATE_REQUEST, sentIntent);
+    sendCvvmMessage(OmtpConstants.STATUS_REQUEST, sentIntent);
   }

   @Override
spammerofspam commented 2 months ago

I'm not sure why activation fails on GrapheneOS yet. It seems to work on the stock Pixel OS. The one weird thing I noticed is that when I'm running GrapheneOS, T-Mobile's website reports the device as being a "Galaxy Note9 - Ocean Blue - 512GB". When I'm running the stock Pixel OS, T-Mobile's website correctly reports the device as being a "Pixel 8 Pro - Obsidian". I wonder if this is why T-Mobile is blocking the activation and deactivation messages.

Unfortunately, I'm not super familiar with the telephony stack yet and have no idea how T-Mobile is determining the model. Maybe things will just work if it detects the correct model.

I took a look at my account, and my Pixel 7 running GrapheneOS shows up as a "moto g pure". Interesting. Is the model that T-Mobile decides a GOS phone is running somehow randomized?

This makes me wonder...is it possible that T-Mobile, on their end, is enforcing visual voicemail (VVM) quirks based on what model they think the phone is? This might explain why some users seem to have no issue whatsoever with T-Mobile VVM while running GrapheneOS, while other users cannot get VVM to work. Hypothetically, if T-Mobile is tailoring the VVM activation response based on which phone model is listed on the account, and if the model is somehow randomized, then some users will, due to chance, end up with a model that has a compatible negotiation with GOS while other users might end up with a model that has an incompatible negotiation.

I have no idea if T-Mobile has such a scheme on their end, though, but it could potentially explain why this seems to work fine for only some users with identical carriers and phone models.

chenxiaolong commented 2 months ago

I was able to borrow a family member's SIM to do some testing. With this SIM, I do not get valid credentials in response to Status:dt=6:

2024-04-20 15:34:53.077632 -0400 I/Dialer  (29756): VvmOmtpService - onSmsReceived
2024-04-20 15:34:53.120355 -0400 I/Dialer  (29756): OmtpMessageReceiver - Received message on non-activated account
2024-04-20 15:34:53.122509 -0400 I/Dialer  (29756): LegacyModeSmsHandler - processing VVM SMS on legacy mode
2024-04-20 15:34:53.123422 -0400 E/Dialer  (29756): LegacyModeSmsHandler - eventType=STATUS, data=Bundle[mParcelledData.dataSize=168]
2024-04-20 15:34:53.124272 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=rc, value=4
2024-04-20 15:34:53.124932 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=st, value=P
2024-04-20 15:34:53.125264 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=srv, value=e6.vvm.mstore.msg.t-obile.com
2024-04-20 15:34:53.125628 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=port, value=1809

(The t-obile.com is not a logging error. The response from T-Mobile actually has the typo.)

Both Activate:dt=6 and Deactivate:dt=6 are blocked, just like with my SIM:

2024-04-20 15:37:49.722518 -0400 E/Dialer  (29756): LegacyModeSmsHandler - eventType=STATUS, data=Bundle[mParcelledData.dataSize=128]                                                                                                                                         
2024-04-20 15:37:49.722823 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=rc, value=0                                                                                                                                                                              
2024-04-20 15:37:49.723081 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=st, value=B                                                                                                                                                                              
2024-04-20 15:37:49.723337 -0400 E/Dialer  (29756): LegacyModeSmsHandler - data: key=srv, value=vvm.mstore.msg.t-mobile.com

Maybe I just got lucky that my line on the account happens to be "stuck" in the activated/ready state.

I'm going to try to do some investigation to figure out why Google Dialer also doesn't work. That might have a different root cause. Unlike AOSP Dialer, it does not use the CVVM protocol for activation with T-Mobile USA.

theuser18 commented 2 months ago

I'm not sure why activation fails on GrapheneOS yet. It seems to work on the stock Pixel OS. The one weird thing I noticed is that when I'm running GrapheneOS, T-Mobile's website reports the device as being a "Galaxy Note9 - Ocean Blue - 512GB". When I'm running the stock Pixel OS, T-Mobile's website correctly reports the device as being a "Pixel 8 Pro - Obsidian". I wonder if this is why T-Mobile is blocking the activation and deactivation messages.

Are you using the same browser? Would'nt Tmobile identify your phone model via your browser's user agent rather than directly from the operating system?

thestinger commented 2 months ago

Vanadium doesn't share the device model in a client hint header but rather uses the same placeholder value there as the frozen Chrome / Chromium user agent. Have you tried using Chrome instead?

chenxiaolong commented 2 months ago

I was able to reverse engineer how the the new protocol works. Unlike the old CVVM protocol, which is based on SMS + IMAP, the new protocol is 100% HTTP-based. The way the JSON data in both the requests and responses are represented is a bit wonky, but not too terrible to deal with.

The new protocol is a bit more featureful than the old one:

Also, it's worth pointing out that Google's server's are not involved at all with this new protocol. All communication is between the dialer app and wsg.t-mobile.com.

I'll first work on a command-line client for this protocol to test out edge cases and then (maybe) work on implementing it in GrapheneOS' dialer. I'll be publishing documentation on all the HTTP endpoints and how authentication works.

Some other notes:

EDIT: Also, I do not plan on doing anything related to transcription. Google Dialer uses its own proprietary on-device ML for transcription (which isn't related to the protocol at all). T-Mobile's own app uses server-side transcription, which is a paid feature. Neither are really suitable for GrapheneOS' dialer.

Trevael commented 2 months ago

Having the same issue with a Pixel Fold but my previous GOS Phone (Pixel 7 Pro) was working just fine but it had not had GOS updated in quite a long time (6 months or more)

GOS Build Number: 2024050300 Carrier settings are auto-set by T-Mobile

Let me know if there is any more info that is needed, thanks!

thestinger commented 2 months ago

Renamed title to make this issue specifically about T-Mobile due to them seemingly not implementing the standard protocol properly anymore.

Trevael commented 2 months ago

Renamed title to make this issue specifically about T-Mobile due to them seemingly not implementing the standard protocol properly anymore.

Seems like its not limited to the Pixel 7 so you might want to consider removing that from the title as well.

chenxiaolong commented 2 months ago

I've finished working on a no-dependency Java implementation of this protocol (and a CLI wrapper around it). Folks who build GrapheneOS from source can play around with it at https://github.com/chenxiaolong/tmovvm.

I've also documented the protocol at https://github.com/chenxiaolong/tmovvm/blob/master/PROTOCOL.md.

It'll probably be a little while before I look into how this can be integrated into GrapheneOS' dialer. I need to take a break after looking at this for so long.

flawedworld commented 2 months ago

Also, the Google Dialer APK you get when downloading from the Play Store is the wrong one and does not include the implementation of the new protocol. Google Play only serves the proper APK if the OS advertises support for the com.google.android.feature.PIXEL_2023_EXPERIENCE feature, which GrapheneOS (intentionally) doesn't.

We advertise support for this on all relevant devices. @chenxiaolong what device were you testing with?

flawedworld commented 2 months ago

@chenxiaolong We might accept a temporary workaround implementing a special case which sends a status request in place of an activate request when we detect the MNC and MCC to be owned by T-Mobile USA. The ultimate goal will be to implement support for their new HTTP API though, however that may take time to be reviewed.

For folks building GrapheneOS from source, this is the little hack/workaround I applied to allow visual voicemail to work on T-Mobile USA. It's definitely not a proper fix, but it seems to work well enough.

# Apply in packages/apps/Dialer/
diff --git a/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java b/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java
index 0df639fcb..4124d5b15 100644
--- a/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java
+++ b/java/com/android/voicemail/impl/sms/OmtpCvvmMessageSender.java
@@ -33,7 +33,7 @@ public class OmtpCvvmMessageSender extends OmtpMessageSender {

   @Override
   public void requestVvmActivation(@Nullable PendingIntent sentIntent) {
-    sendCvvmMessage(OmtpConstants.ACTIVATE_REQUEST, sentIntent);
+    sendCvvmMessage(OmtpConstants.STATUS_REQUEST, sentIntent);
   }

   @Override
flawedworld commented 2 months ago

I think the CVVM protocol is a dead end. I was able to test with another family member's phone. This device is not misdetected on T-Mobile's website and the SIM card has only ever been used with a Pixel 7 running the stock OS. CVVM activation is also blocked there. I think it's clear that T-Mobile has deprecated support for this protocol.

I suspect this was done to reduce risk of malicious parties hacking into IMAP mailboxes by sniffing SMS traffic for VVM credentials.

flawedworld commented 2 months ago

It seems quite unfortunate that now 2 major US carrier networks, AT&T and T-Mobile, are now rolling their own VVM implementations.

flawedworld commented 2 months ago

For reference in an ideal world GSMA TS.46 would be followed and heavily updated to not suck. https://www.gsma.com/newsroom/wp-content/uploads/TS.46-v2.0.pdf

Amusingly T-Mobile in the Czech Republic uses GSMA TS.46 and helped author the latest standard.

EDIT: This shit literally uses 3DES for encryption.

chenxiaolong commented 2 months ago

We advertise support for this on all relevant devices. @chenxiaolong what device were you testing with?

Sorry, I completely missed that in /product/etc/sysconfig/. I was only looking in /system/. Google Play may be using another mechanism to determine which variant of the Google Dialer APK to download then.

@chenxiaolong We might accept a temporary workaround implementing a special case which sends a status request in place of an activate request when we detect the MNC and MCC to be owned by T-Mobile USA. The ultimate goal will be to implement support for their new HTTP API though, however that may take time to be reviewed.

I got a chance to test on every line in my family's account and this workaround appears to only work on 2 out of our 5 lines. It's not universally usable and probably isn't worth the effort to add a temporary workaround.

I suspect this was done to reduce risk of malicious parties hacking into IMAP mailboxes by sniffing SMS traffic for VVM credentials.

Agreed. The new HTTP API is quite ugly in some aspects, but it does require 3GPP-GBA authentication for every single request. No more non-expiring IMAP credentials.

chenxiaolong commented 1 week ago

I finally got a chance to look at how the AOSP dialer works and it unfortunately is pretty closely tied to OMTP. There are protocol abstractions for certain pieces, like VVM activation, but it expects everything else to be standard OMTP (eg. for downloading voicemails). Adding an HTTP-based protocol would require changes all over the visual voicemail implementation to add a more flexible protocol abstraction.

There's also a lot of unused and half-implemented code (eg. voicemail greetings) in there, seemingly from when AOSP and Google's proprietary dialers started to diverge back in Android 5.

Sorry, I don't really have much interest in untangling that right now. I was hoping it'd be more straight forward. If anybody else is interested in doing so, see my comment above (https://github.com/GrapheneOS/os-issue-tracker/issues/1951#issuecomment-2095182625) for a link to the protocol docs and a sample CLI implementation.