Since my last update on snapd patching for Ubuntu Touch support things have moved. We are not fully where we want to be though with regards to supporting every device at our disposal.
To move things over from GitHub discussions into a broader forum, and to update people on what’s missing I figured I should do this here.
Since Ubuntu Touch devices use Halium (https://halium.org) as a hardware support layer it has different needs from a mainline Linux device. It loads both the familiar glibc as well as Android’s bionic libc into a process and uses it.
Now, since there are two libc’s at play and they might have different ideas about what to do with memory, we run into “funny” situations. And this is where this post is aiming:
We still have to add a missing piece for Halium/Android 10 devices by Mediatek in order to support Snaps with their OpenGL ES drivers. These particular devices have a GLES library that has a different ideas about thread-local storage than glibc and its memory layout and size. This causes a process loading both glibc and bionic into memory to crash on Mediatek devices of that generation.
For H10-Mediatek devices to work with Snaps we need a way to LD_PRELOAD them into the confined target Snap. We’ve not come to a conclusion but one idea I wanted to put out is potentially shipping this in the currently supported core Snaps, and having snapd/snap-confine set the appropriate LD_PRELOAD value under those circumstances for it to pick up the TLS padding hack. It’s not pretty though, I know, so I would like to get some input as to how to proceed here.
We have a rough idea on what to do with adding Snap browsing capabilities to our OpenStore app shipped preinstalled with Touch and the OpenStore website, but I would prefer not jumping ahead of ourselves.
Adding to that, frankly, the speed with which we have been proceeding on the Snap-on-Touch topic and the lack of interest in the LD_PRELOAD topic leaves a bit of a bad taste in my mouth, for reasons everyone should understand at a glance. I mean we have been asked already if we would like to build on Snaps completely for Touch but this lack of engagement proves why this is not a viable solution for us.
Such one-sided interest definitely leaves bad taste. If snaps would be adopted but UBPorts or in more broad concept, community concerns should be answered when ether possible, even with “I don’t know, I will ask around”
As of my link - I was thinking about technical side of searching snaps in Open store using API-based method, or just develop something specific for UBPorts project, which would use such API on both side for easier cooperation with upstream in the future. I’m terribly sorry if I misunderstood something in that topic
I see, yeah whatever could ease our implementation of browsing functionality on the website would be helpful. I will pass this on. For on-device installation we will probably just go with the QML bindings in snapd-glib since that’s where we’re home, in Qt land.
As for the duration of the effort here: the first (abandoned) PR was issued Jul 2023. Work must have started shortly before that if memory serves me right.
If would Ubuntu Touch need more industry traction then it is somehow required for KaiOS devices using low cost phones but also some attention weird phones and when there is adoption in situations where not fully android phone is required but symbian is big no no, then todays and future limited environments and not so wealthy people could use this ecosystem if somehow advanced… And Google thinks so if invested…
So a few supported phones with few apps when some android apps(or something) is required for work then ubports effort seems not in so well position toward countries problems… with paying for phone a lot more to be able have some ubports with 3 editions supported and phone gone into the void…
Thank you for your interest in this thread. As you may have noticed, the subject is Snap integration in Ubuntu Touch (UT), not porting of UT to more devices. That discussion is probably better had on the relevant Ubuntu Touch community channels.
Today I had the opportunity to work on snapd enablement patches further and released Snapz0r 1.4.0 for Ubuntu Touch. This brings snapd changes in line with reviews and has enabled Docker installation support as well: https://open-store.io/app/snapz0r.fredldotme
If this particular change is of interest I am willing to propose a PR asap, as it fixes the long-standing issue of not getting Docker installed on Touch properly on any kernel release, and the notes regarding devmode snaps starting other snaps makes very little sense IMO in the context of Docker.
If it justifies the noise, here are some changes coming up to support snapd use-cases on Halium-based operating systems:
Snapz0r (current version 1.4.1 now 1.4.2) Is the snapd enablement installer for Ubuntu Touch Focal and provides snapd 2.63+git (at “some” revision) of my snapz0r-140 branch on GitHub. There are some patches that separate decision making for the process environment based on device’s cgroup functionality.
Device cgroups and their abilities to secure the environment turn out to be buggy on some device ports based on Halium, hence requiring some changes in how to behave should one cgroup feature not be working as expected.
It also carries flags for detecting whether running on Ubuntu Touch or not. These flags are added by Snapz0r itself to /etc/os-release to enable extrausers or support for setting up various properties in the libhybris environment. Plus it sets environment variables in case necessary for the libhybris glibc wrapper libraries to be picked up.
Snapz0r 1.5.0 has been released slightly over a week ago. It’s basically a rebase with a few setup steps taken care of to avoid filling up the system’s rootfs partition with apt caches and files.
The interested among you might have noticed the commit about Docker support on Ubuntu Touch which, since the last time I talked about this at Ubuntu Summit 2023, allows for detecting Ubuntu Touch as the host. This, according to Convergence, should allow for development tasks on a tablet device with mouse and keyboard. The way it is set up is by avoiding the complex AppArmor Regular Expressions which cause incompatibilities on the various Android vendor kernels we provide.
Upstream input on how to get this ready for inclusion would be nifty.
