Ubuntu Touch Q&A 101
Focal news, New devices ported, Optimizations


Looking for the Audio-only version

of the Q&A?  You're just one big orange

button away -->

News and Update

UBports Q&A 101 on 5 June 2021. The show was presented by Dalton and Alfred this time around.
A reminder to everyone who has not yet watched the ‘Love letter from the community to the community’ which is posted on our YouTube channel to check it out.
Go to devices.ubuntu-touch.io for info about whether your device is supported.

Focal 20.04 development news

On Focal, 20.04 is progressing well. Rpowerd which operates the power button and wakes the device is now in there. Tonegenerator (the clue is in the name) has now been integrated, along with autopilot and autopilotQt. The latter invokes a testing framework for things like accessibility data, in order to run an application automatically. It is like selenium in the browser but for Qt. Rachanan got all of Lomiris tests passed. The module which handles the spinner and potentially will handle switching sessions now integrates properly with Lomiri. With those things and others we are now very close to the first pre-built test system images based on 20.04. There is no promise that this will be done in the next two weeks as there may be some dependencies which we haven’t spotted yet. Having pre-built images also does not mean that you will be able to try those out in a test channel. If you could, there would be no way back and you would discover that while the image ‘works’ it isn’t yet capable of running applications!! In the initial stage, this is about being able to boot a graphical desktop based on 20.04 but that is a huge milestone.

New devices added to UBports installer 

Some new devices are starting to come onstream. Six in total in the installer, in the past couple of weeks. Ari has ported the LG G4. The Pixel 2 and the Pixel 2 XL are both now in there. Those are courtesy of Florian. The Pixel 3aXL was done by Alfred. The OnePlusFive/5T has been done by Vince. Also the Xiaomi Poco F1 by Joel is in, together with the Xiaomi Redmi Note 7 by Nikita. 


Ari, as many people know, is putting a lot of time into providing documentation on various things UT related. He has put out a survey to gather feedback from Android 9 porters, so that he can understand the most effective approach to documenting their efforts and make porting easier. What he does need though is responses to the survey! If you are porting, please reply to him as this will make your tasks easier.

MediaHub in Qt now

MediaHub, the thing which fetches media and flings it out to applications, has been completely re-written in Qt instead of Boost. About 20,000 lines of code were changed, so a huge undertaking. It is in Devel and will very soon be in rc, so later this week check out any app in UT which uses media (not including Morph browser, which has its own arrangements). If you notice any oddities when playing back media please let us know, as this was a very big set of changes. Some advantages are a small (3MB) memory saving and faster operation. Most importantly, maintaining it just got way easier and adding new features in the future will be much more straightforward. Praise Mardi for the work on that.

Drawer and Messaging app fixed

Dalton also found some time to fix some of the issues with the VM. The EFI builder builds on 64 bit Intel platforms. Incidentally, this is a Wayland thing, not Xmir. Basically, what that did was to expose a lot of bugs, especially with the drawer. It could be drawn out but was then reluctant to go back. Dalton managed to fix some of the bugs found that way, so again that has tidied up our code. A problem where pressing the power button would do nothing has now been fixed.

There was a regression in Messaging app, which has also now been fixed.

How can you help

A lot of people ask what they can do to help out with UBports, so a brief re-cap. If you are a porter, answer the porting survey. There are two fixes in the works for online accounts. If you are a PinePhone user, this should fix online accounts for you. Please, please if you have a PinePhone, test this out for us before we merge it! PR number 17 is the one to look for. If you want to sign in to your Google account [ahem] there is a fix for that too. There are instructions on how to test that one out but a warning to try it only on Devel. Do not attempt to run it on rc. That one is at PR number 16.

MMS is still used in some places (especially the USA) and there are five new Prs which together attempt to fix the issues it has. If you are super-keen, please think about testing those changes for us and let us have your feedback. One of them is in Go and overall they are pretty heavyweight changes.


The News section of our Forum is the best place to post questions for the Q&A. YouTube live chat, Telegram and Matrix are other places to post a question.

If you didn't know, the Forum questions get priority.


Thieb has noticed that NFC works with some Android 9 devices. Is it the intention to extend that to all Android based devices?
Well Android 9 provides a great abstraction layer for NFC and we had an excellent starting point because Volla had already used that to implement NFC on their device. Other devices would be way more difficult. Xperia X is also potentially an easier case because it has a special kernel implementation for NFC that we may be able to exploit. No luck with that yet though. It would take a lot of time for someone who is really interested in doing something about it but at least there is a possible path forward for that device. Older devices have kernel versions which do not provide for support. Certainly none of the core team has further development of NFC as a priority.

Old devices and upgrade to 20.04

Thieb also asked whether the upgrade to 20.04 will mark the point where users finally have to think about getting rid of devices such as OnePlusOne, Nexus 5 etc? Well the death of 3G is a thing anyway, so our own changes are secondary. It is time to move on, as far as the Nexus 4 is concerned… Same with BQ 4.5. Hey, you got a lot of use out of those :)

Basically, until we have images actually running and we have a chance to test them on the whole range of devices, we will not know about any compatibility and performance issues. Systemd has kernel dependencies. That is a fact of life. Older devices have older kernels and there will inevitably be roadblocks. There would nearly always be theoretical solutions but we have to ask ourselves whether the huge effort involved for some older devices would be worthwhile and in general the answer would be no. [If most surviving examples of a device are starting to see hardware problems and there are only five or six users anyway, honestly it is time to move on.] Six or seven years use out of your phone is pretty good.

UT debug menu

UT does not have the debug menu that is available in Android. Is that relevant to ‘normal’ users? It would give information about battery status, CPU, sensors etc. If you wanted to know signal strength for example you can get that by using the UT terminal but there is no existing graphical interface. If that was thought to be useful it could be implemented. If someone fancies doing that, their efforts would be welcomed.

Morph password manager

Alaraajavamma bought UT devices for everyone in their small company, as they were so impressed. There is only one big sticking point. Morph browser does not have a password manager. How difficult would it be to build one and are there any plans to do so? There is a document on the QtWiki, describing qtwebengine use cases. It marks auto-fill and password manager as things that are lacking. It would be interesting to know if there are any browsers out there which are based on qtwebengine (as Morph is) but which have had that functionality added. If so, it should be a simple matter to port their solution over into Morph. There is some danger that doing that would slow the browser and unfortunately as things stand there is no upstream solution available. A solution would exist in the C++ portion of qtwebengine and that would be GPL, so no problem with licensing and authorisations. The facility is needed for sure but there is a question mark over whether we have the resources to attain it.

Potabi with Lomiri

Gizmochicken commented that Potabi devs are planning to start porting Lomiri to Potabi in 2021. Do we know anything about them and are we working with them? It is FreeBSD apparently, for phones. The developer is in the Lomiri chat, so yes we are in conversation with them. The timeline looks very over the top. It may not pan out in quite that amount of time but great that they are aiming high.

UT devices lifecycle

Jan-ops79 asked what the lifecycle support will be for UT devices? The turnaround on Android is around 2-3 years and iOS it is around 3-4 years. Interesting is the fact that in hardware terms a mobile phone can keep going pretty well for around ten years? Also, how is the bounty hunter idea coming along? Each case is different. Reltionships with Pine64 and Volla for example are both positive but different in character. We have no control over the actions of either of those partners, so there are unknowns about their devices. Support is all about having people able and willing to put the hours in and if they lose interest in a device, it will fade. That factor is more important for sure than the issue of whether the hardware is still capable of functioning.

Project pledged financial support

There was a discussion on the forum about trying to advance call and SMS functions on the Pixel 3a by some sort of pledged financial support. Probably the question is about that. There would be a spin-off to similar Android 9 devices, for use with US carriers. There have been some expressions of interest and willingness to put money forward but nothing has been collected in yet. A crucial thing is that we don’t yet have a volunteer with the skills to do that work. If they step forward, we could certainly put that plan into action pretty quickly.

There is a general openness to doing something like this, if we can figure out the implications for taxation etc. Direct linkups involving a small number of donors don’t have those administrative complexities. [Disclaimer: UBports Foundation does not underwrite any ad hoc arrangements.] Before you ask, we have applied five times to BountySource but we have never had a response…

Apps compatibility

Aurelio asked whether making UT apps compatible with Fusible and similar would generate more interest from developers because they would be serving a wider base? How is the Flatpak runtime work going? This goes back to some discussion with KDE who pointed out that in theory our apps could run as Flatpaks. Tobias and Nico don’t have write access to that sub-project but they are welcome to have it if they contact Dalton about it. At this point, it is failing in CI. It is another one of those areas where it is a very nice idea but we don’t have the resources needed to pursue it.

Roadmap for developers newcomers

Totalrando asked whether there is a roadmap that newcomers with technical expertise can refer to, in order to see where they might help with low level fixes etc? With better signposting, more people would offer? On a related subject, Dalton is about to begin work as a mentor, helping out a technology student. He is both terrified and excited about it. We are not exactly swamped by those volunteers but Dalton’s approach is to ask them to list five things which really annoy them about UT. He then identifies the one that probably has the most straightforward solution and advises them how they might go about fixing it. Annoyance is a pretty good motivator. If you are editing in QML that is great because you can do it directly in your device and reboot to see if it had the intended effect and didn’t break anything.

Any GPU and WebGL news?

Domubpkm asked is there any word about GPU or WebGL for Volla or other smartphones or is all that on hold? Actually we merged something just last week on that but it caused an issue with Nexus 4. We need to figure out what is happening there.

Fully functional Linux based phone

Tim Harless asked in live chat when a ‘fully functional’ Linux based phone will come to fruition? Well that depends on what is meant by the question. In terms of a phone based on Linux which is capable of being used as a daily driver, that is already here and is UT. [Lots of people out there have expectations of wide support for Android apps and proprietary services; also for a fully fledged desktop OS on a phone. If that is what ‘fully functional’ means, no we don’t have that and probably never will.] As Dalton pointed out, all phone operating systems have bugs and design issues which grate with your personal requirements. Android and iOS are not ‘fully’ functional. They have things you won’t like and can’t do anything about.

Tim also asked whether there are any plans to pair with a hardware manufacturer to make a UBports phone? It is worth reading up on Volla phone and PinePhone. You will see that we have been working very closely with Volla and Pine64 and both have hardware which runs UT. The Volla is functional, whereas the PinePhone was always intended as a development device, not as a daily driver.

In addition, Tim asked what the biggest issue is around getting app developers to start developing apps for the UT platform? Developers who come from Android or iOS are used to a sophisticated and fully integrated system of development platform, testing, beta release to a store, publishing etc etc. Our systems are not that slick but they are pretty simple to operate. We use Clickable, which allows the creation of projects, building them, deploying them and even enabling a debugging module to be opened up on a computer. It is all there and easy to use but access is not as simple as it might be. You have to learn the initial commands to set up the development environment. Clickable is already good but it is under constant development itself and is always improving. A weak point is app development documentation online. We need to get better at that. You can run IDE for QtCreator with Clickable, which greatly extends it. It could all maybe be packaged in a more intuitive manner.

Canonical support and cooperation

Finally, does Canonical contribute to the project at all and what outside bodies contribute [code]? As mentioned above, Pine64 and Volla have both put money into projects which utilise UT. In the Volla case, that involved deploying their own software engineers to UT development, to the benefit of UT across the board. Check out the UBports Foundation. We created that as a solid, official structure which could provide the formal relationship that businesses need before they can conduct partnership working.

As far as Canonical is concerned, we have former and existing Canonical employees who support us on a paid basis or in their spare time. The Mir team in Canonical are especially helpful to us. They are building Mir for their own purposes but they take into account how we might be affected downstream and kindly take account of our needs. There are Canonical trademarks which we are permitted by them to use, subject to some very reasonable constraints. We also of course use Ubuntu as an upstream, so we get not only the thing itself but of necessity a constant flow of security updates which directly benefit us, at no cost to us. That amounts to a pretty huge contribution from them.

Where can you find Alfred and Dalton

Alfred shamelessly plugged his Twitter feed but he does have a lot there about his UT related projects :) Follow on @fredldotme
Dalton is on @universalsuperbox on Telegram. Don’t open with ‘Hi’ or you may not get a response. State your business at the start.

See you next time :-)

Interview with Alfred E. Neumayer