Ubuntu Touch and Linux Kernel Version
-
There are two ways to run UT. With Halium, which is a Android driver compatibility layer and is thus tied to the Kernel used in the Android release for that phone, usually 3.x but can be newer.
Or you can run it without Halium like the PinePhone or on a RasberryPI in which case you can use what ever Kernel is supported by that device. -
UT itself is not tied to a specific kernel version (other than it needing to be at least 3.4).
However, devices which originally shipped with Android and have proprietary blob drivers are tied to the kernel they shipped with, due to the internal API/ABI of the kernel breaking often, so the kernel version can't just be upgraded on those devices.
On more open devices like PinePhone, Librem 5, Raspberry Pi, or PCs, where this limitation doesn't exist, the upstream linux kernel can be used, without any Android parts at all.
-
So UT itself has no Kernel dependencies? No issues with whatever the Wayland, Xwindows, Mir/XMir is? So the display servers have no tie to the Kernel?
I understand the issue of device drivers tied to the device and provided by the device manufacturer. But there are also drivers that are shared by multiple devices such as bluetooth, ofono... just wondering if those don't care about the kernel either
-
@rob Basically we have a minimum requirement of a kernel version, but thats very low, as Canonical was in the same situation: They needed to support 3.4 for example, or maybe even older kernels in the beginning. But, as far as we can see from our Pinephone and Librem5 inverstigations, newer kernels are perfectly fine.
It is really only the proprietary driver part that keeps you from upgrading (and receiving security and bug fixes) for your Android device. However, Bluetooth for example uses driver backports from 4.2, apparmor 3 is also backported. So, the kernel is a big mess of vanilla kernel, AOSP patches and cherrypicks by Google, vendor patches, and our own patches
- its a miracle it ever works. -
Also its a Linux kernel, but consider it rather like a fork - every second patch you try to apply fails as it has diverged from vanilla. And on top, its more like every vendor made its own fork in the worst case. How nice, we got suddenly 24 different flavors of kernel to maintain
Thats why everybody is excited about Non-Android devices: We will finally be able to get that complication out of our way.
-
Thank Florian. That is my understanding as well. I looked at some of the discussions in the past about the Bluetooth backports and such that you were involved in.
And this has interesting implications if I'm understanding this right. It means UT has more flexibility in the future than I imagined. I though that beyond device drivers, there was something else tying UT to an older Kernel.
I thought that PostmarketOS had an edge over UT because it uses a mainline Kernel. I'm so glad to hear that this is not the case. I thought about developing apps for UT but was concerned about a possible dead end at least for an app that's not maintained by UBports.
So, the Pinephone version of UT uses mainline? That's confirmed?
-
@rob Yes its confirmed to be 5.x not sure which minor version though
-
While we're at this, can a GTK app run? Is there some emulation built in already in the main UT? Or this is possible only under Libertine? I haven't tried it yet.
I'm thinking I'll have to rewrite in QT.
-
Is there any difference e.g. in performance, stability etc.. between a halium or non-halium device?
-
@rob I dont think GTK will work out of the box. It will work in Libertine I think. Consider Qt whenever possible, its much more mobile friendly.
-
LOL. I learned GTK for the Librem5. Actually without QML they are fairly similar. But I had to ask, one never knows...
I should have asked the reverse. Would QT work on the Librem5 PureOS and my guess is it can be made to work. In which case, I should have just stuck with QT.
So QT it is
-
GTK+ 3 (whatever version of it is in Ubuntu 16.04) will work out of the box on UT today, although it will not work as well as Qt/QML does.
PureOS is using a much newer GTK+ as well as their libhandy which depends on newer GTK+ I think. Once we have fully switched to Wayland as the client protocol, though, one should be able to include a build of the latest GTK+ and libhandy into the click package for an app, and it should just work roughly as well as it would on PureOS.
-
thanks dobey. I will test it out when I get the chance.