Coordinating Ubuntu Touch enablement

Hello!

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.

What we did in Ubuntu Touch with regards to Clicks is to LD_PRELOAD a do-nothing library that just adds padding to thread-local storage in order for both to have a roughly same idea about what to do with TLS. This is all it does: https://gitlab.com/ubports/development/core/hybris-support/tls-padding/-/blob/main/tls-padding.cpp?ref_type=heads

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.

Input welcome.

2 Likes

Additionally, I think this might be useful if we would want to have snap-compatible backend for UBPorts or develop custom client if necessary: https://dashboard.snapcraft.io/docs/reference/v2/en/index.html

What specifically about it?

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.

1 Like

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 :slight_smile:

Plus, for how long such efforts are ongoing?

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. :slight_smile:

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.

1 Like

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.

1 Like