News and Update
The frequency of the Q&A broadcasts has reduced sharply but that doesn’t at all mean that activity has ceased.
Pixel 3a full coverage and Aethercast implementation
Starting with what is happening with the existing 16.04 based version of UT, Alfred was very pleased to announce the first port of Halium for a device which achieves 100% feature coverage! The device is of course the Pixel 3a, which Alfred has been working on for a long time. Since device development is continuous, this covers a greater number of features than were present when Canonical presented UT phones with a full feature set. The device initialization is much improved on previous devices. It uses UDEV in Java keyboard. It is using only one partition and does not run an initramfs like other devices.
There are no audio issues now when the device goes into sleep mode, so you can listen to music in the background without it cutting out.
The final thing which brought the device to completeness was the implementation of aethercast. That is the system which allows wireless external display support. It is compatible with Miracast, the Microsoft version. At present it only operates at 720p. Next on the list with be 1080p capability, along with 60 fps.
If you look at Twitter, you can see that Arubislander and others have been testing out the casting capability of the Pixel 3a, with their own equipment.
Lomiri has received some attention. There was an issue with the drawer hiding away under the mouse counter and that has been fixed.
Another fix deals with stretched push indicator icons when in desktop mode.
An issue with rpowered which prevented maintenance of the wake mode when programs had made a call on the system has also been resolved. Devices which have seen problems with suspend when dealing with tasks should see an improvement.
Our Devices page has ‘wireless external monitor’ listed as a category but for most devices that shows as a No. Now we have a yes. It is an awesome feature. You can use it to switch to your desktop mode on a large screen. Most devices supported by UT don’t have an HDMI out or equivalent, so wireless is the only option. Scale is not an issue so it will work with a big screen, for example to show slides in a lecture. We have quite a long way to go with providing business oriented functions on UT devices and this is a very important step on that road. Not having to carry a laptop to a meeting room would be great!
The aethercast option is contained within the UT build but is not on by default and for each device, the porter needs to fine tune the implementation before it can be used at all.
There are strange chips in some devices which are unable to support P2P mode and will therefore never be able to support aethercast.
Device porters should contact (best via the porting group) to find out what they need to do in order to enable aethercast on their devices.
The Lenovo tablet is another device that porters have been able to test aethercast on.
This is all about creating an entirely wireless version of UT operating in desktop mode, on the go. Of course it will not have the full functionality of a Linux desktop computer because ours is a mobile system; nevertheless it has a lot of potential for carrying out tasks.
It isn’t clear whether the dongle (which you need to interface the TV or monitor) operates on 2.4 or 5 GHz. It also isn’t clear whether that can be selected on the dongle ( it can’t be selected on the device). Maybe someone knows? Wireless video streaming takes a lot of bandwidth and occupies the same space as Bluetooth etc. so you may get issues with a local setup. As in the past, our only certain knowledge is that the Microsoft dongle is compatible. Others may be but we have no information about that. Feedback from the community about whether other dongles work would be much appreciated and we will pass that information on.
A question was asked about aethercast security. That was not something Florian was able to answer and he suggested reading up on it! What we can say is that it is a standard WPA WiFi interchange and for sure it cannot be more secure than the WiFi setup you are using.
Remix asked whether it would be a good idea for UT devices to have a dock? That has been asked for many years. Marius once worked on a multi-functional concept that he called a ‘station dock’ but it got lost in a sea of urgent things which needed to be done. The idea was for a cable (HDMI) video connection, so a better quality of output.
Alfred pointed out that his Jingpad has a magnetic attachment which allows a keyboard to be added to the tablet, to create a ‘laptop’. Not quite the same thing as a dock but has some of the same potential.
OTA-23 rc is out
OTA-23 release candidate is out. We rely on users to feed back their experience of new RC channel updates, so that we can correct any problems before moving it into Stable channel. With this one we have had some memory issues reported, for example. Some apps have been killed by mini crashes.
There are some improvements to the Messaging app, made by LionelD. On the project board on our Github page you can examine all the changes.
Backlight dimming when switching the device off or on was variable, based on the brightness of the screen. If you had it on full intensity, that could delay the shutdown for several seconds. That is not as trivial as it sounds. If you switch off your phone in bright sunlight and put it in your pocket, if the screen is still active it can hit record and send :( Florian has made a fix which also deals with the situation where you had to hang around for a while after asking your phone to wake, before it would do anything.
There was a strange bug which prevented the ‘&’ symbol displaying correctly when posted into an SMS message.
A lot of people have probably forgotten that FM radio was once a cool feature of smartphones and Alberto has been able to bring that back for some of the BQ devices, Poco X3 and some other Qualcomm based devices. He created a mini app which helps you to tune in. It will not work unless you connect wired headphones, as those were always part of the reception mechanism. It is in the early stages and a bit experimental but we will shortly add an FM category to the Devices page, so you can check whether your device is supported or not. Incidentally, it works in the background so you can continue listening when the screen goes dark.
Some of the changes are quite technical and not so obvious but there are 25 changes in all, so this is quite a major upgrade.
UT based on 20.04 news
Now to 20.04. More components, such as QtOrganiser have had the Focal treatment. ADDB has had some work done to enable pluggable authentication mechanisms. USB modeD has been implemented, allowing ADB/SSH functions. Porters and app developers will be very interested in that. This will enable direct deployment and debugging on a real phone environment.
Overall, there are now more hooks which enable developers who are not in the core Focal team to start engaging in a practical way with debugging and testing. As access is improved, more hands can get to work and that should start to speed things up.
None of this means we are yet at the ‘soon’ stage.
Our challenge is not just to ensure that 20.04 will work on your device. Our plan is to make the change by what for the user will be a ‘simple’ process of channel switching, just like doing existing upgrades in 16.04. Of course hidden behind that will be enormous complexity, especially with so many devices. We need not just a working system but a flawless infrastructure for delivering the system. That means two huge projects, not one.
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.
Why Ubuntu Touch exists
B.Karloff wondered why UT exists and why it is better than Calyx OS or Graphene OS? A fundamental difference is that UT is not a type of modified Android ROM. It is not a ROM at all. Unlike the Android alternative, it cannot run .apk files. Privacy covers a multitude of things. For example, Lineage OS without the core Google apps already releases you from a lot of the privacy issues which you encounter when using the Google ecosystem. What it does not do is remove all the privacy aspects which come in to play when you load Instagram or Facebook onto it. The UT approach is to simplify by stepping away from those megacorporation apps which have a business model based on data collection. Rather than being only concerned with privacy, we also want to help you to detox your digital life. UT is about providing functional, useful devices, while stepping away from entertainment and distraction.
Within that, we are not setting out to deny options or to make it unpleasant to use! We can innovate in a way that the big players simply cannot because they are tied into the logic of the gigantic, highly standardized products they have created. The mass option is “Here is our product, take it or leave it”. There is no room for feedback or a change of direction. As a community, we can take UT in any direction we want.
With a ‘desktop’ mode and Libertine containers, a UT phone can become an effective and very portable work tool. We tend to always compare with Android but we need also to draw comparisons with iPhone and iPad, which are the ultimate in the locked down approach. They do some things in a highly consistent and slick manner but you can do only those things, nothing else.
Many smartphones these days have more RAM than the laptop you may have on your desk. They have fantastic computing power. Mostly, that power is used in rather trivial ways, such as playing handheld games. In desktop mode, there is a lot of business and technical potential which could be unleashed.
Samsung DEX and all the others cannot do what we can do. They are not the same. Our apps need to be designed so that they morph automatically between a mode suitable for a phone screen and a mode suitable for a desktop environment. The user has no ‘setting up’ to do. One app, two environments. Seamless. This is not like a phone app ‘talking to’ a desktop app. They are both the same thing.
Other systems are not ‘convergent’ in the way we use that word. Our chameleon apps shape shift and adapt to the environment in which you view them. We didn’t swap out the chameleon!
20.04 development details
Kristatos asked about the state of 20.04 development. In rough terms, where are we and also, where are we with VoLTE? There is a lot of work on detail and at the same time everything is being slowly moved over to Gitlab. Alongside that we are making changes to our branching architecture. Mike from Debian is doing an amazing job on packaging because remember we are also making what we have available to the upstream, which for us is a two-way development street. We have to sanitise all of our components to prevent bugs carrying over and beyond that we still have device-level builds to work out. As we have said before, we don’t know for sure which devices will get a build at all.
We know that systemd requires some kernel patches to work. If it turns out that we can only do that for kernels at 3.13 or 3.15 and above, that will automatically rule out support for some early devices. Nexus 6P for example has 3.10.
Even if 20.04 was ‘complete’ there would still be the device level testing and adaptation to be done.
Florian reflected from his own experience that in software development, timelines kill productivity more than any other factor.
For sure there will be some devices which get test builds of 20.04 before others. That is how we will make progress. Building for one will teach us lessons for the others. There will not be a ‘big bang’ delivery of 20.04. It will roll out gradually.
Kristatos also asked about progress with VoLTE. In North America, the situation around VoLTE is a major pain. 3G networks are being switched off imminently. A major issue is that there is no standardization in the way different devices achieve VoLTE. There will definitely be no single solution that will work for all. A few devices offer an easier path and we can probably fix those. With others, the mechanisms are so complicated that we will probably never get VoLTE working on those. In North America, you may have to choose from a narrow range of devices if you want to use UT.
This time around it seems that Mediatek devices are usually a little bit easier and Qualcomm based devices a bit more difficult. All of the other alternative phone projects are having exactly the same problem. At the moment, there are people not in the core team who are trying to disentangle how VoLTE works on different hardware and what solutions exist in principle. With work on 20.04 ongoing, the core team has no time to construct solutions based on those insights.
Reverse engineering 3000 lines of code that we don’t understand is a huge task and this is an area where every manufacturer does their own thing.
This block will be with us for quite a while, so many in our community in North America have switched to SIP as a way of making conventional calls. Fortunately we have the Linphone app, so this is perfectly practical but of course does not offer quite the same functionality.
Android 12 support
Sanath.usk 0 Is there any plan to support devices based on Android 12. With the introduction of GKI it should be easier than with previous Android versions? Florian and Alfred were very surprised at that suggestion! On paper it seems yes but in terms of the features which we need there are likely to be problems. Things like Apparmor will very likely break the binary interface. The mechanisms which allow the kernel to ensure that drivers are working properly are probably incompatible with the changes that Google is introducing. That doesn’t mean we won’t be able to do it at all but the idea that life will be easier with GKI is certainly wrong.
When Alberto was working on the FM project he brought in kernel patches from the old BQ devices. It is known of course that those devices run very nicely with UT but when Florian did a comparison with much newer ports he found a lot of that useful kernel content missing. We need to look into that because it seems that we have quite a lot of redundancy in the range of kernel changes which we apply these days. If we don’t really know why some of those are there, it makes sense to weed them out and go with fewer, as we used to do.
Our kernel checker is very comprehensive but we didn’t get it from Canonical. It probably came from the Mir project some time ago and it is likely that it was written for desktop functions. Much of it is probably not applicable to a mobile environment.
Remember that we are still not done with Android 10 and 11! Actually 10 is in a pretty good state now. 11 not so much. It is a bit premature to start worrying about Android 12 at this stage.
App development, Waydroid support
Martijm says that he is very interested in doing some app development for UT. Is running apk apps using Waydroid officially supported? Well, Waydroid is at this point not officially supported, so no. It is simply there to be tested if you want to try it.
Although not ‘official’ Florian has a Waydroid container on his device and within that he runs Slack, which he needs for work. At the moment, Alfred finds that his banking app ‘just works’ within Waydroid. Maybe it shouldn’t but hey…
With some devices such as Pixel 3a, the battery drain problem is not entirely gone but it is possible to live with now.
App development, Clickable
Are there many webapps in a Clickable container? Erm, no. A Clickable container is an environment which is used for building apps.
If you look in the OpenStore, you will see alongside each app what type it is. Some are webapps. After a lot of concern from users, the policy is that apps should not be bookmarks pretending to be apps! Webapps are permitted but they must have some complexity. The app which provides Twitter access is a nice example of a sophisticated webapp. It would be much nicer of course in most cases to have native apps rather than webapps. As an example, getting push notifications to work with a webapp is very difficult.
As well as using Clickable to compile an app, you can run QtDesigner inside it and even debug with it. You can even run it on your device, with GDB, with break points. Clickable also runs QEMU and interfaces with directories, so it is pretty amazing.
App development, Krigami
Can kirigami applications made for Plasma be made to run on UT? Actually, yes they can. Florian has a recollection that some of the dependencies are a bit outdated now and would have to upped by a version or two. The best way forward is to clarify which kirigami app you have in mind and then ping Florian to get some pointers on the resources needed for that.
App development, Flutter support
The last question was about Flutter support. Android 9 and above support Wayland, so there is nothing in theory standing in the way of it. Most of those who say they would like Flutter do not seem to be platform or framework developers, so who exactly will do the large amount of work needed? ‘Cross-platform’ is a bit misleading, as each platform needs its own independent customisation layer. W are not talking about platform agnostic apps that work out of the box. Maintaining a customisation layer is a lot of work in itself and it goes on forever, so this is not a ‘free of effort’ option.
If someone wants to do that work of course they can and it appears that doing it under 20.04 will be quite a lot easier than doing it under 16.04.
We are not sticking to the fortnightly schedule of Q&As these days but as it happens there will be a two week gap this time and on 25 June we will have another one and there will be a guest. You will have to tune in and watch to find out who the special guest is. We are not announcing that ahead of time ^^
See you next time :-)