Ubuntu Touch Q&A 106
New apps, Porting news, SD card management fixed


Looking for the Audio-only version

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

button away -->

News and Update

UBports Q&A 106 on 14 August 2021

Florian and Alfred hosted this time.
Go to devices.ubuntu-touch.io for info about whether your device is supported. The documentation to help people port devices to UT has been greatly expanded and improved, so make sure to check it out.

New apps

In the OpenStore there is a new app which can play radio streams using MediaHub. That means that the app does not have to be in focus while it is playing, so it will still work when the screen is off. It is called Radio by Patrick Fial.

Another is an app which can play internet video streams, such as YouTube. This is very useful because videos play pretty badly in Morph browser. In the app you can either enter a URL or search for terms. A very nice app called MiTubo from Alberto Mardigan.

Scooter by Patrick Fiall shows their location on Bird and even unlocks them with a QR code. Very handy if you have those in your city.
It would be great if someone put up a video of themselves using that app, to illustrate the ways in which UT can be used.

Finally there is the Corona app, which reads the immunization status used throughout the EU. We thank arnef for that. It can display a barcode which can be scanned for entry to transport, venues etc.

Developers are welcome to draw attention to their new apps in the Q&A forum thread.

UBports Board of Trustees

There is some information in the blog about becoming an official member (or ‘trustee’) of the UBports Foundation. Those people will have the ability to vote in elections for the board for example. The bigger the number of voters the better, so if you are eligible because of your practical involvement with UBports, we would be pleased if you make an official application to join. Members will be able to put themselves forward for board elections and membership committee elections.

Porting news 

New in porting is a solution for a bug that prevented Oneplus 5 and other devices operating properly with two SIM cards. In fact any Android 9 based device was affected and some even has a problem with a single SIM. The fix will be in the next OTA but of course you can try developer and later rc channels to get ahead.

The Halium build for Android 10 devices is now starting to make some good progress. Nikita has been the great force behind this. He has been the only one really able to untangle the problems. He has added masses of patches from upstream and Sailfish. Florian was amazed that his ‘secret’ Android 10 device is now so settled with UT that he can switch over to it as daily driver. There are some things not working but they are not essential for Florian. His device has 8GB of RAM and 128GB of flash storage. Sadly what it does not have is HDMI out. The most unusual thing is that it has a replaceable battery. It is the Shift6mq. The device has an SD card slot so if for some crazy reason you wanted to, you could add another 512GB of storage. Apparently it can support DisplayPort via USB-C. Calls, Bluetooth, all the cameras and wifi work. Video recording doesn’t work yet but that will not bother most people. Getting the phone to this point involved a lot of manual fixes and those don’t exist as a build that is ready to use. You will have to wait a bit longer before it is available in that form for general use. It is hoped that some representatives of Shift can attend one of our future Q&A sessions to talk about their phone. Their philosophy is to make a phone which will last for much longer than most of those you can buy today. The other side of that is it is expensive to buy initially, though the ‘price per year’ will be more reasonable. It is intended that repairs will be easy to do. They also believe in a circular economy, so when you buy from new you will pay a deposit and when it is broken or you give up on it, you send it back to them for re-use and salvage, with a refund of your deposit. Go to shiftphones.com and you will see all the details.

This is the first of the Halium 10 devices but be patient and eventually there should be a lot.

Alfred has been doing a lot of work to refine the Pixel 3a. The big step has been getting Waydroid support into the kernel. Alfred has tested that and it works pretty well. Importantly, the tests with Bluetooth headphones were successful. This will be very important to some people. Auto-brightness is on the way to being fixed again. There was an annoying bug which made the video recorder freeze when the stop button was pressed. It did actually save the video in that state but it was an inconvenience. That too has a fix in the works.

Halium 10 now has a recovery with an install script embedded, so that is a good preparation. Halium 10 has a ‘super-partition’ which makes it a little bit more complicated.

For halium 9 devices, we have been working to solve in call volume problems. It would be very helpful to have porters test the fixes to see whether they work on every device. For those who are trying to compile for Halium 9 on Mac OS a segfault problem there has been solved.

A reminder that the UBports forum is a great place to ask questions, avoiding the risk that in Telegram they will get buried in a mass of messages and be lost.

If you would like to help with something, the forum is also a great place for that. Just find a heading which seems to be near that subject and post your offer there.

SD card management 

There are some things coming up in OTA-19. One of these is SD card management. Ejecting and formatting SD cards has been broken on UT for the past three years. Alexander Martinz from Shift fixed that very quickly. Nobody raised any issue about it but we are fixing it anyway.

A couple of regressions which appeared on the devel channel have been fixed. Sensors and rpowerd had stopped working together. The effect of that was that if you answered or made a call by raising the phone to your ear, the screen would not switch off as it should. The other problem is that the camera and media stopped working. Something was changed that we were unaware of, possibly in the upstream. We have the fix now but if for any reason you don’t want the latest update just yet, you can clear the gstreamer cache and that will fix it temporarily.

Quite a long time ago Florian conducted a survey to find out what users think are the most important phone features to them. It is time to refresh that, to make sure that we are putting effort into the things that you rely on the most.


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.

20.04 progress and PDK testing feedback

We have a huge amount going on at the moment. Some of that is in the background but two very big projects stand out. The move to 20.04 is absolutely necessary and we are progressing well with that but it is taking a huge portion of our resources. Next on the list is VoLTE support, which we have only got as far as scoping. That is becoming more urgent and we will certainly have to deliver on it, to keep our phones able to make calls in the future. We know that the VoLTE project will be very complicated and difficult. We will need to shift away from the old Canonical framework and invent our own. The bottom line is that it will take money to do that.

If every active member of the community donated the equivalent of $10 a month, at least until delivery of 20.04 at the end of the year, it would give a major boost to that work and allow some features which we would otherwise be stretched to include. We are working 100% with the core developers we have. The only way to achieve more would be to hire in some developers and that needs money.

Ratchanan has continued his work on 20.04. He has fixed a mismatch between systemd requirements to access for example the network and an Android firmware need for those calls to be within a set group. System image clients have been updated by him, which will eventually enable on phone system updates. Those updates should allow the switch from 16.04 to 20.04 to be done without having to use the UBports installer. The third piece of work was by Marius who has made some changes to the PDK (Platform Development Kit) recipe. Basically, this means that virtual builds within PDK will be exact representations of the same builds working in devices but without some differences which were due to un-merged elements. If the PDK system does not behave exactly as the device system, it becomes useless as a way of testing.

There has not been much feedback yet about how the PDK is working. Like everything else we need testing, bug reports and suggestions for improvement so please start those coming in if you are using it. One new feature under development is the ability to export proposed changes from the PDK, so that they can be flung out in a usable form to people outside the core development group. That will enable new fixes and suggestions to be tested for real on devices before the changes become a firm proposal. It is not in yet but Alfred will have it ready for use soon.
The Gallery app has been tested inside the PDK running a 20.04 build and it works. Similar tests are also happening with morph browser.

Notes app

Totalsonic asked about the core Notes app. Evernotes is a proprietary product and its free version is limited to a small number of devices. It would be nice to have our Notes app expanded so that it works with a range of other sync note taking platforms too. Well at the moment we have the free-standing Jotit, which works very well. Could that maybe sync with Nextcloud?

This is obviously not something for the core team but it would be great if a community developer jumped in. Totalsonic just wanted to throw that out there. It would actually be good to have Nextcloud notes support not just in Jotit but in the core Notes app too. A solution probably lies with some volunteers outside of the usual suspects because they already have their hands more than full. A solution could be pluggable rather than tailored to Nextcloud. There is obviously already an interface between Notes and Evernote. It might be that a lightweight solution would be to explore that mechanism and then put in an abstraction layer so that a lot of what is already there can be re-used, with just modifications to suit a range of other targets.

Florian has issues with an apartment project right now and needs the kind of organization that Notes can provide but aside from the fact that Evernote is proprietary, he doesn’t like the way they organize and present information and would very much like an alternative. Notes is fine as it is for typing in huge amounts of text but what most people need is a simple list and reminder format, not a facility to write essays on their phone.

Remember that we don’t even have sync in Contacts yet, so there is a long way to go on that. Just a note that Krille made the Jotit app, so a big shout out to him.

Bluetooth support in 20.04

Olga.bio asked a question about Bluetooth support in the 20.04 builds and whether we can expect any improvement in functionality? It is true that 20.04 will bring in a set of newer tools for Bluetooth support, so we will have something better to work with. Unfortunately it is not just a matter of software. A lot of issues stem from phone hardware and each device will have limitations. We would expect that some things will work better and other things will start working for the first time. It is complicated though, so expecting better stability overall is overly optimistic. Remember that although we are still on 16.04, we have done a lot of backporting in the kernel for enhanced Bluetooth support, so the jump will not be as big as you might expect.

Probably more of an advantage can be got by shifting to a more modern device with a more advanced kernel, offering improved driver support. Florian can say from personal experience that backporting Bluetooth fixes is a very painful process. So much effort is involved that trying to bring good functionality to 5.1 and 7.1 devices would be difficult to justify. We have limited resources and 9.1 based devices already perform far better on a range of metrics. We have to say again that if you can, it is time to move on from those (now) very old devices. They are cheap but they will fall further behind and of course their hardware is breaking. Even with Android and iOS, with their huge resources, Bluetooth is often flaky. That illustrates how messy and complex it is.

Transition to Lomiri components

Opaijavai also asked about 20.04 and the transition of Ubuntu components to Lomiri components. Will that force a change in design philosophy and drive us towards QQC2? Giving the specific example of SpinBox for app building, the Ubuntu components don’t provide support for that.

It has to be admitted that QQC2 is the likely future of QML because it offers a lot more widgets and flexibility, so yes that will reflect in our UI. Yet again, it is all a matter of workloads. Although we expect this to happen it is not an immediate priority and you should not expect it to happen at the same time as the 20.04 release. It will come as a later stage. It is possible to mix but even with basics like clipboard and keyboard that can get very messy and throws up problems. That was found with TELEports. Ideally, Ubuntu components could be given a QQC2 and Suru makeover. Remember that the Ubuntu components were created from scratch by Canonical before we even had QQC1, so the issue of compatibility never featured.

If this is a field that interests you and you would like to contribute, the place to head is our UBports UI and UX group on Telegram.

Lomiri in desktop distros

Truocolo asked in live chat whether it would be possible to package Lomiri in desktop distros? The answer is absolutely yes and that is our intention. Of course the way Lomiri works needs to be different in a desktop environment. The most obvious example is the set of indicators that we use on the phone. We will need relevant replacements for those. It was very much the goal of Canonical when they ran the project and of course Lomiri on desktop would be a natural gateway into the UT project.

UI swipe up functions

IsThisAvailable had another UI question. At the moment, swipe up from the bottom of the screen is restricted to particular functions within the app that is in focus. It has not been given any system-wide role, to avoid conflicts. Could this limitation be removed so that e.g. split screen can be triggered from anywhere?

Florian pointed out the location of the go back function, which is at the top left, well out of thumb reach. That is of course why Android has it as a physical button, bottom left. If we had a swipe up system function it would get in the way of simple scrolling in the browser for example. You would likely go back when you didn’t want to. This is a general issue about one handed operation and something we need a debate about. If you have some ideas, please let us know and the UI team can think about what would work best.

App-images instead of Click packages?

Povoq asked about options for moving away from reliance on Click packages, not by Flatpak which seems unwieldy but maybe by using App-images?

Well App-images are just application containers. We would need to be able to serve them so there would have to be a compatible app store. The permissions system which we have is unique and it is not at all clear how we could adapt that to interface with App-images. Rodney points out that the big downside of App-images is that they contain everything they need so there is a lot of redundancy and they take a large amount of space. There may be a use case for a small number of them to be accommodated but as a default they would certainly not be practical.

We have essentially one platform while Android has a multitude of different builds and each app has to bring its own support components, to fill the gaps in every different build. So their apps are bloated. If updates are taking place over mobile data that is not just about the use of storage space but involves all the extra (expensive) data use.

Clicks work really well and are deeply embedded into our architecture so there is no question of them being replaced or even ceasing to be our main form of packaging for apps. It is one thing to enable other app formats to run but quite another to achieve full integration with the system to allow use of camera etc. and to allow exchange of data with other apps. Just bringing animated stickers to Teleports meant adding two more libraries. Implementing calls in Telegram will be two or three more, then another two or three more for video calls. It starts to bloat quickly… The even worse aspect is that you might have to import a library that is 20MB in size, when you only need functions in it which are equivalent to maybe 400 kilobytes. You have to take the whole thing, you cannot extract just the bits you want, which is hugely wasteful.

Snap and Flatpak despite their own difficulties do allow for cherry-picking functions from libraries, so they are not so bloating.

An associated topic is how we might start to introduce some background functions for apps. Automatic syncing is the obvious example. It is something else that we need to discuss.

TELEports Gif support

Podcast Ubuntu Portugal asked about Gif support in TELEports Actually that is a very hard thing to do. Telegram themselves want mp4 to be the default video format. Animating Gifs would mean introducing an embedded media player to TELEports, so basically a huge job. There is a further problem that our Qt video player automatically competes to grab any video source.

See you next time :-)

Interview with Jeroen Baten