Ubuntu Touch Q&A 109
OTA-19 rolling out, Focal development and Miracast support progress

 
 
 

Looking for the Audio-only version

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

button away -->

News and Update

UBports Q&A 109 on 25 September 2021.

Dalton, Marius and Alfred presented, this time around.
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.

OTA-19 rolling out

OTA-19 is rolling out to all UT devices on stable channel, right now. The base is still 16.04 but there is a new framework for app developers, affecting in particular Qtwebview. We now have gyroscope and magnetic sensing added to the supported sensors. That is not for Halium 9 yet but on Xperia [or any 5.1 or 7.1 based device] you can now use the compass.

In messaging, the keyboard would sometimes pop up on auto for no reason and that has been fixed. If you find that there are still instances where this occurs, let us know.

Password entry interface problems, especially on Volla Phone, have been resolved.

Music will know pause if you unplug your headphones. That broke and is now functioning again.

Just to emphasize, an OS is only as good as the bug reporting that goes into it. Everyone, no matter how newbie, can contribute to that and we really appreciate that feedback, which benefits everyone.

LinuxAfterDark

Dalton has launched a new podcast called LinuxAfterDark. You may have listened to him before contributing to Late Night Linux Extra and it is a remodeling of that with the same contributors. First episode is on the Monday after this Q&A. From then on it will appear on alternate Fridays.

Focal development 

Marius has been working to fit Focal to the range of different UT devices. The system image creates a tarball, which it gets from CI. It puts that into a dot file into a folder then add-ons outside that. They are uncompressed but the compressor/de-compressor is unable to figure what it is supposed to do, so the install is messed up and it breaks the device. Using Python’s tar directly is quite primitive and yes it breaks. Marius has done a lot of untangling to get that flow working properly, however the next problem is that it fails at the boot stage.

Done manually, everything works fine and Marius has been testing updates from upstream in Focal and those are working nicely.

His work on Qtmir and Lomiri has continued. The focus at the moment is Lomiri on laptop, where there are some pretty tough bugs to sort out.

There was a brief excursion into Gnome not supporting XDG protocol, unlike Lomiri. Sway are having some influence though. But enough of that…

Miracast support 

Alfred has continued his work on Miracast support. An initial problem has been solved. Frames can now be captured and sent across to Miracast. Screencasting the phone’s screen works but the virtual monitor that is supposed to contain the full-blown desktop shell is still subject to some color format issue, causing the screen to stay black. At least we have so far succeeded in feature parity with Android. What Alfred may do is to provide a switch function so that you can choose between a desktop mode and a phone screen-casting mode. These issues should be resolved over the next couple of weeks and the setup does seem to be delivering at 30 frames per second. Switching between resolutions is no doubt something that many people would like but there is no easy way to deliver that.

Pulse-audio patches and Libayatana upgrade

Rachanan has now got a patched pulse-audio and the pulse-audio module’s droid. Libayatana has been upgraded. We are working closely with the Ayatana developers, particularly with a view to using their indicator set in UT, to replace the old Canonical indicator set. They are working to fuse the histories of each set together, to remove the need to manage each stream separately. Ubuntu Mate could use either, in principle.

We are importing and renaming a lot of settings schemas, as well as splitting them out into different packages to make them easier to maintain. The aim is to put in that effort to rationalize now, so that we can reduce our effort in the future.

Sponsors were thanked.

Questions

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.

Nexus 5 and Oneplus 1 support

The first question was by Alter about the Nexus 5 and Oneplus 1 asking for clarification of the suggestion that they may not be supported in the future. Is it wise to advise newcomers to buy these old devices still and of all the new devices on offer, which ones are the most future-proof? Another questioner puts it simply as “What is the ‘new Nexus 5’ going to be?”

Alfred’s view is that ‘good at everything’ aspect of the Pixel 3a makes it a worthy successor as go-to device. It is a Google phone, so pretty open and quite widely available. It already has quite a wide user base, which means that it sees a lot of refinement through mass bug reporting. If you want brand new, the Volla phone is available fresh off the production line with UT installed.

What about the Canonical announced extended LTS

AppLee asked about the new policy of Canonical, which means that the security aspects of LTS for distros are extended to ten years of coverage. Does that change mean that UT also has security support for that ten year period? Canonical  offer a commercial package of support for server use but that is not applicable at device level, so the answer is no. There is a certain amount we could achieve by repackaging updates intended for 16.04 but that would take a lot of work and would have to be balanced by slowing progress towards 20.04. In practice that would make no sense. It is better to fall behind with 16.04 in order to bring forward the point where we make the jump.

Whatsapp reverse engineering

Thousandtopics asked about a scenario in which an app developer had everything they needed to reverse engineer a Whatsapp app. What, in theory, would you ask them to add or remove from that app? One of the first things that people ask about when they arrive at UT is whether they can continue using Whatsapp. It is ubiquitous and it is the thing all their friends and family use. However Whatsapp is notoriously hostile towards third party clients which try to access its service. Even Signal is better in that regard. They will always shut down a custom app. Not only that but they shut down the customer accounts associated with any custom app. We don't want to be party to any individual being locked out of that ecosystem.

We do have a webapp (they do allow limited functionality via browsers) but even that needs to run alongside an Android (or iPhone) based account running their official app.

Android 12

Thousandtopics also asked whether we ought to be taking a close look at Android 12 now, so that we can anticipate how we might make use of its architecture for UT builds in the future? In one sense things have become a lot easier with Treble. On the other hand Google likes to shift around the boot processes for each release, for no obvious reason. Each time we have to adapt to that. In 12 they have changed to optional initramfs and away from non-optional.

We still have work to do on Android 11. Google have enough money that they can choose to move at any rate they like. We don’t have that luxury. We have to take one step at a time. It isn’t just about budget. Having the money to do it but not the suitable people wouldn’t work out. Actually we have been speeding up and closing the gap so we are lagging less far behind than we did. Google are utilising upstream kernel progress much faster now, which is also of help to us. Their new policy is to focus on getting things right in the upstream kernel first before allowing that benefit to trickle down into the system.

Rasppberry Pi and Ubuntu Touch OS

On ARMhf or ARM64 based software, yes it can in principle run on UT but that doesn’t mean it is easy. It isn’t easy to just export drivers from Raspberry Pi and use them in UT. We have to also go back to the fact that the Pi although small is aimed primarily at desktop so there are all the usual scaling issues to consider. ‘Running’ is not really the point if it is not touch-friendly and you need a big magnifying glass. Forget Gimp on a phone. It is a daft idea.

Multi-boot

Scout1 wanted to know about multi-boot. Individuals have hacked ways to get Android and UT working in dual boot on their devices. It isn’t technically impossible. If you have that setup, updating the UT part will not affect your Lineage install but the minute you update Lineage, that will wipe your UT. For a stable system you would need an Android installer and a UT installer which only update their own slot. As with many things, if someone wants to put that effort in they can but it is not something that the core team has any time to look at.

You do not want a situation where userdata is shared, so the logic is that you need separate partitions. Alfred has experimented with this on the Pixel 3a and discovered that you cannot create an additional partition there because the architecture does not allow it. UT is not currently using the A/B slots for updates. Mixing elinux and apparmor is another source of trouble

Many in our community explicitly want to get Google out of their lives and have no interest in having an Android build on their device. We could not throw ourselves whole-heartedly into efforts to dual boot. Recognising that some Android functionality has its uses, our way forward is Waydroid, which is designed to run three or four of the niche (parking, banking, tolls etc.) apps that you might need in daily life.

Cooperation with Droidian

There was a question in live chat about whether we are working with Droidian around anything other than the Halium parts. No, they certainly have some input into the Waydroid work but their input is to Halium rather than UT directly, which is at it should be. We are of course happy to talk at any time. Erfan has mentioned that there are some camera functions which could benefit from their input, along with some aspects of our browser. We and Droidian have very different architectures, so it is not a question of any disagreement between us or any unwillingness to cooperate. Our system needs are very different in practice, so the extent to which we can share solutions is pretty niche.

To the question “Can you just make UT work more like Droidian?” the answer is no. We are doing different things. It doesn’t mean that one is right and the other is wrong. We wouldn’t expect Droidian to “do things like UT does them”. Go with the one you like. UT is not and does not aim to be an ‘old style desktop Linux on a phone’. Our approach is that like Android, UT should ‘just work’ out of the box for consumer level users with no technical expertise. If you use apt it is only a matter of time before a conflict arises and your phone is wrecked. We use systemimage so although in theory we could mess it up, the user is not going to, by anything they do.

We celebrate the fact that users have UT to choose if that is what they want or Droidian if they want ‘Debian on a phone’. There is room for both.

Pine OTA synced updates

On whether the PinePhone OTA is synced with the general release, well no it isn’t linked in the technical sense but usually the buttons are pressed at the same time so the updates arrive together. This time there has been a bit of slippage because Dalton took a holiday but he undertook to get the Pine update out there.

See you next time :-)



Ubuntu Touch OTA-19 Release