Thanks to recent developments, SMS and MMS fixes for users of various Halium 9 ports such as the Pixel 3a (XL), OnePlus 6, and others make it possible to get reliable SMS and MMS (only with wifi disabled right now) working for North American carriers, which previously had not been consistent.

• Note: Even with these fixes, MMS incoming group messages aren't delivered to the Messages App correctly. MMS Photos work fine in and out, and sending MMS group messages work. Here is a brief guide to getting this working:

SMS

• IMS services need to be disabled as part of the port, since if those services are running then carriers may detect your phone supports IMS and convert the way they deliver SMS to your device causing all your SMS to go down a black hole!
  • Pixel 3a: please move to the "RC" or "Devel" channels, which have the patches already applied to disable IMS services.
  • Other devices: if you receive 1 SMS after boot then no others, it likely is IMS interference. You may need to contact the porter of your device to discuss with them disabling IMS services.

MMS

• Step 1: Apply MMS patches

  • Note: for the Pixel 3a using "RC" or "Devel" channels, only the first patch for "nuntium 8" will actually make any changes.

• Step 2: Install updated ofono and ofono-scripts packages.

  • Somehow get a terminal running on your device: recommended is enabling developer mode in System Settings > About then using adb shell when connected to a computer via USB-C. Otherwise, you could connect via ssh [if you have that set up](link url).

  • Run these commands:

    • sudo mount -o remount,rw /

    • wget https://ci.ubports.com/job/ubports/job/ofono/job/xenial_-_android9_-_usissue/lastSuccessfulBuild/artifact/ofono-scripts_1.21+ubports1+0~20210819100145.2~1.gbpb9f999_all.deb

    • wget https://ci.ubports.com/job/ubports/job/ofono/job/xenial_-_android9_-_usissue/lastSuccessfulBuild/artifact/ofono_1.21+ubports1+0~20210819100145.2~1.gbpb9f999_arm64.deb

    • sudo apt install --reinstall ./ofono*.deb

• Step 3: Reboot

Again, at this time, MMS send and receive only work with wifi disabled. If you have issues with your APN Settings then try to Reset ALL APN Settigns, reboot, and re-enter them based on your carrier specifications. Note that another bug prevents setting Internet and MMS as the APN type: use MMS only, but do NOT create a duplicate APN for Internet in this case: 2 APN entries with the same APN will cause MMS to not work! So effectively, in this case, just set up the APN for MMS only and Internet should also work.

Join the UBPorts [North America Carrier Issues] if you need interactive support in getting SMS / MMS working.

Is there any consideration in having a separate build that is not a read-only filesystem, e.g. more of a standard Ubuntu install? If there were something like that, I would think it could stand as the main development branch that would allow faster upgrade to 20.04 / wayland / systemd / etc. Then it could be a testing ground that new releases of the "stable" or "consumer" read-only system would come from.

It would also not frustrate any potential developers who want "standard Linux on a phone" (mobian, manjaro, fedora, etc.).

In summary, I understand a lot of the reasons behind the read-only system for stability, for security, for end users, etc. but I fear it keeps away possible developer interest that would benefit Ubuntu Touch in the long run if it were more "traditional Ubuntu" on a phone?

People could be trying all sorts of things like flatpak / snap / different apps, etc. I know there is Libertine but there is some performance issues and it isn't available everywhere, etc. So take the chains off and see what happens? I suspect a large growth of the community (???)

@ubportsnews there have been different comments here and there on some possible contract work for enabling VoLTE being undertaken by someone outside the core development team. Can you comment on or link to this work so we could have a better understanding of it?

Since it seems a solution may need to be a combination of software + firmware support will it be a case-by-case basis to have devices support VoLTE or will it be able to be enabled for all Halium 9+ devices for example?

Updated Nov 6, 2023

Last year when T-Mobile shut down their 3G servers (and said they were going to shut down their 2G servers as well) we thought it was the end of the road until UT would support 4G calls (VoLTE). In fact many have left UT as their daily drivers because of the lack of telephony functionality since that time.

However, the T-Mobile 2G servers are still functioning until April 2024, so they can be used for calls as a stopgap. Note that time is running out, hopefully UT will support VoLTE calls before 2G is shut down!

Also note that in 4G mode cellular data works fine, but calls do not auto-negotiate down from 4G to 2G and so incoming calls will be missed. Previously when the 3G network was still up, UT would auto-negotiate down from 4G to 3G when a call was coming in, meaning the phone could be kept in 4G mode. But with 3G servers offline and no auto-negotiating down from 4G to 2G for calls it means leaving the phone in 2G only mode is the only way to reliably receive and make calls. Data speeds are slow, but that saves your MB! So use 4G mode for speed (but no calls) or 2G mode for calls and slow speed

Until relatively recently, we used to have to set multiple APN entries (one for cellular data, a second one for MMS), and this was confusing because many providers only have a single APN, so we had to use a mixture of APNs from multiple carriers to get around the problem. Thankfully, we can now correctly use the Internet + MMS APN type in UT, so it is much more simple to set an APN correctly.

Below are some collected APNs for T-Mobile and T-Mobile MVNO carriers in the USA:

T-Mobile USA APN Settings

Used For: Internet + MMS
Name: T-Mobile
APN: fast.tmobile.com <NOTE: do not use t-mobile.com it will not work!>
MMSC: http://mms.msg.eng.t-mobile.com/mms/wapenc
<Proxy, Proxy Port, User Name, Password ALL BLANK>

Alternative:
Used For: Internet + MMS
Name: T-Mobile
APN: epc.tmobile.com
MMSC: http://mms.msg.eng.t-mobile.com/mms/wapenc
<Proxy, Proxy Port, User Name, Password ALL BLANK>

US Mobile APN Settings

Used For: Internet + MMS
Name: US Mobile
APN: pwg
MMSC: http://pwg.mmsmvno.com/mms/wapenc
<Proxy, Proxy Port, User Name, Password ALL BLANK>

Mint Mobile APN Settings

Used For: Internet + MMS
Name: Mint Mobile
APN: wholesale
MMSC: http://wholesale.mmsmvno.com/mms/wapenc
<Proxy, Proxy Port, User Name, Password ALL BLANK>

Tello APN Settings

Used For: Internet + MMS
Name: Tello
APN: wholesale
MMSC: http://wholesale.mmsmvno.com/mms/wapenc
<Proxy, Proxy Port, User Name, Password ALL BLANK>

To make sure the settings are applied, after changing APN entries please reboot.

Note that, yes, it is known that 2G audio isn't great for calls, but hey it is a functioning phone!

Please reply here with other MVNOs that may work in the USA, I will keep updating this post to stay current.

Thanks again to everyone for the hard work. I am a big supporter of this work, but am a bit lost: the recent work seems to be focused around multi-window, etc. for desktop, which I would think is 2nd level priority over getting apps to work well "full screen" for phones. Is it all needing to be done at the same time, or can enough polish be made for phone users first, then those testers and feedback can inform desktop work as a 2nd stage? Maybe phone use is already polished enough, but I have thought it isn't ready to test yet?

@UniSuperBox

"Don't worry, your grandfather died doing this work!"

That was a strange way I was greeted one even in Khartoum, Sudan, in 2010 as it was well past sunset and I was still working away on the network infrastructure at the NGO I was volunteering with. The speaker was this elderly Sudanese man who was encouraging me that I couldn't get it all done in one night, so take some rest. His words sounded funny though because my first thought was: "Huh? My grandfather didn't know anything about running CAT5!?!" but as I thought about it what he was saying was "you can't do it all, there will always be more to do than 1 person can do." In some ways that is "fatalistic thinking": will we never make it?? But it is also true.

So this is what I am acknowledging and passing on to you to, good sir:

"Don't worry, your grandfather died trying to get 20.04 out the door."

So, wishing you a good break and a re-kindling of passion. We will make it with help from the community that ebbs and flows but continues on.... it may not be as you thought it would be when you first took on the reigns as Development Manager, but you have led us a long way, and you deserve some rest and acknowledgement that your effort was so appreciated by so many.

@joshndroid thanks for starting the thread.

All developers and contributors, thank you for everything you have done to bring us to where we are today with Ubuntu Touch.

@UBportsNews I have understood from previous Q&A sessions that some of the major development goals include:

• moving to systemd
• moving to 20.04 base
• moving to wayland

Any updates on these goals and how they inter-relate? systemd for example we heard briefly from Marius went better than expected when working on Lomiri for Manjaro Arm.

Erfan posted this reply to my above question on telegram:

"Hey i was just going to reply your post in forums that noticed you are already in group so if u don't mind i'll answer here

first of all thank you very much for your support, really appriciated
but recently focus was in finalizing application managment in display instead of a full android screen
for weekly report i just said said multi-windowing but in reality the work behind of it was more for detecting/selecting open apps in screen

now i'm working on a sever-like tool to glow this pieces together and have something usable for users with proper app managment"

@jezek Good explanation. I think you are right because at this time the devel and rc images both have the same package versions, so switching between them would not change those bits.

Previously when rc didn't have the new packages this technique of going between rc and devel would ensure you would get them installed when going to devel, but now as you note going to stable then to rc or devel is needed.

OK this has been discussed here already: https://forums.ubports.com/topic/5593/problems-navigating-ui?_=1616043859494

I just tried increasing "Ubuntu Tweak Tool > Edge Sensitivity > Edge drag areas width" (it was a 2 before, trying 4) and it seems to address the issue. I'll report back after a few days usage, but this may be the setting I didn't find before.

Can you give any update on Anbox development, which I have heard has some dedicated developer effort behind it?

Also, can you help us understand the specific ubports team efforts to Anbox apart from upstream Anbox development? Maybe mainstream is focused on desktop / amd64 base while ubports team is of course targeting for phone / arm? Is it hoped to eventually submit upstream the ubports work?

Thanks again for all the hard work. Keep it up team!

https://github.com/ubports/anbox

https://github.com/anbox/anbox

@d0od said in I have ended my contract with the UBports Foundation:

I appreciate I'm not popular in the Ubports community

@d0od don't sell yourself short, I (and I am sure many others) have great appreciation for your work and all you do for the Ubuntu community (and, as an extension, the Ubuntu Touch community): we all benefit from your contributions. :call_me_hand_medium-dark_skin_tone: :clapping_hands_medium-dark_skin_tone:

@applee Thanks for the reply. I have a case which has a raised edge, so it is hard to get to the edge properly. Also I have a glass screen protector. So that could add to the challenge.

On the pinephone, I have a raised edge case plus a glass screen protector that is slightly too small (it is for a Moto G7 Plus), so that makes the edge a bit difficult.

Trying a bit more I had to increase the N5 edge setting to it's max, 6, but it seems to work better (still it doesn't detect sometimes)

@stanwood yes, understood it is a community project. I am curious about the core developer perspective of working together with others like this.

Personally I think it is a good way to work since the core team doesn't have the time or capacity to work on this right now, so the community can step forward to support it getting done.

Hopefully all the work will merge together nicely to benefit everyone. BTW I am a contributor, I really am hopeful for this work!

@keneda typo fixed. yes it is only with wifi DISABLED that mms is working. WIth wifi on UT doesn't know to send / receive MMS over cellular since wifi is preferred.

Looking through https://devices.ubuntu-touch.io/ and comparing phone availability / price / features on swappa has me thinking the Google Pixel 3a (XL) should or could be considered the next device to carry the Nexus 5 / OPO torch as the next generation preferred / promoted device? Am I wrong?

@fizz currently a single APN for internet and mms is not supported. You need to have 2 separate entries, one for Internet and a second with a different APN value for MMS. How we have "tricked it to work" for T-Mobile is use the tmobile entry for Internet and a MVNO entry for MMS. This has worked for T-Mobile customers (that don't have a US Mobile contract but still use the US Mobile MMS APN settings), and likewise for US Mobile customers (that don't have a T-Mobile contract but still use the T-Mobile Internet APN settings).

For ATT it is similar.

Without knowing the Canadian market, do you know of any resellers of Virgin Mobile? If so then we can hopefully solve this issue for you.

The PR that is hopefully going to make a combined "Internet + MMS" APN possible (so you can just have the 1 APN entry) is here: https://github.com/ubports/ofono/pull/28 but at least in my testing it is wiping out any manually entered APN settings often, reverting to default settings. So I fear it may not be immediately ready for inclusion without some further development / debugging.

Here is the Telegram group for "North America Carrier Issues": https://t.me/+ohNz4o-TY_E1MmM5

@jezek said in MMS success and failure:

I will do some other fixes in nuntium in very near future. Besides I will try to investigate where your "Invalid URL" error happens and why the URL is empty. If I don't respond in one-two weeks, please ping me.

Thanks for your continued work with MMS!

@ronbillock said in MMS success and failure:

@rik I had created a group on my wife's phone that included my wife, her sister, and our 2 daughters. I sent a picture to them with a text message saying it was a test and asked them to reply to the message with a picture of their own. My wife's sister just replied to the group message with 3 pics and some text. It came through just fine. It seems that as long as it is in response to that same group or that group thread then it is OK.

A problem I believe this creates is that the only access to this group they have, in order for my wife to get the message, is by responding to that specific thread. I am curious, if one of them were to delete the thread and then send a message to the same members (a new thread) will my wife then receive it or will we be back to where we started?

I am waiting to hear from the other recipients. Also if any one of them were to add an additional person I am not sure what will happen since they will not be in the group I established? I guess one step at a time.

I think MMS is not smart enough to know if someone deleted the thread or not. As I understand as long as the group members are the same then it should deliver correctly if you have the group thread on the receiving UT phone. Think of it like this: MMS doesn't really know what a "group" is, the message itself just itemizes all phone numbers at the beginning of it (sorry you weren't able to see the raw text, that should work with wget but regardless it seems you are getting there now). So it isn't like "Telegram" or "Whatsapp" or "Signal" that has a concept of true "groups" that people can join and leave. Instead it is just a container for a set number of phone numbers: any change to those itemized numbers means a "different group". IF things were working correctly, then each time there was a different set of phone numbers a different group message thread would be created. But as you are seeing the BUG is that no group message thread is automatically created. This means you will unfortunately need to try again with wget on failed MMS downloads to see what phone numbers are there, manually make the MMS group (message thread), then download again to populate that message thread. A BIG headache for you, but if you do it right you will at least be able to get all MMS messages. And in time you won't be getting infinite variations on who the group members are and things should settle down (just adding messages to existing group threads). And then in time hopefully UT messages app gets smarter with regard to being able to auto-create the MMS group thread. I don't know if @jezek has this planned or not at this time.

So, if you want to try again with wget (finding the http address of the failed download from Log Viewer in nuntium.log we can see if we can help you dig through how to identify the various phone numbers in it to manually create the group thread). In fact, try this process of wget on a MMS group message you successfully downloaded, then it may be more apparent how to read it. They shouldn't be blank, if so something else is causing confusion.

Finally, just noting that MMS Group Messages are far from supported / polished in UT. Any chance you can convince your contacts to join Telegram (best support on UT)? Then you can get the messages on your desktop as well, etc. and it is more secure than MMS. No I haven't convinced my family members to do it yet, either