I’m one of the maintainers of Ubuntu Touch and would like to give Snaps an opportunity to shine on our beloved mobile OS.
I’ve started an investigation on how to enable our mainly libhybris-based selection of devices to allow running Snaps effectively and efficiently a few months back and would like to share the information with you, to further allow the implementation of Snaps to happen on Ubuntu Touch.
The way Ubuntu Touch developed, it stayed pretty much a hybrid-design between Snap-based and classic-based Ubuntu. We have a read-only rootfs with various /var, /etc and so on directories moved and bind-mounted over to a /userdata partition (which is always provided by the Android partitioning scheme). Additionally though we run a minimal, stripped down version of Android in a LXC container, solely for the purpose of driving the hardware using blobs shipped by the vendors, and using a vendor kernel.
With Ubuntu Touch based on 20.04 we support kernels 3.18 and up, which means very little new features pour into our device port kernels. The exception is AppArmor which we mostly clone from Ubuntu’s kernel git history, importing the closest security/apparmor changes to the version of the vendor kernel.
Now, to support Snaps on our unique device-kernel-rootfs design a few things need to happen:
Enable OpenGL drivers to work in a Snap environment
Allow certain /android directories to be mounted over into the Snap
Have the glibc-based OpenGL & EGL wrappers use bionic-based OpenGL libraries
Enable Snaps to communicate through Android’s binder interfaces
As a result of many of those 4 points being taken care of already in an initial patch set, we get this:
These are Wayland apps running on the Pixel 3a on Ubuntu 20.04, in wireless desktop mode.
I would like to get some initial feedback or ideas of how you would like to see this implemented. I can of course clean up the patches and propose them in parallel while we work out general questions.
Just making sure I braindump everything here before I forget it again.
Since it seems desirable to some to leave snapd disabled, due to unfinished ports not enabling everything on their side (AppArmor), we could ship with the snapd systemd unit being masked and allow the thing via a system-settings feature or an app from the OpenStore.
Of course it also needs work on our side in terms of playing well with the rest of the system and renaming everything to Lomiri in the past year or so means existing snap permissions need adjustments for their DBus APIs to be allowed in AppArmor’s view. /etc/system-image/writable-paths would need some fine tuning too.
I’ve just picked up tests in that area and found two different issues, both of them related to AppArmor installing either LXD or the Docker Snap.
One is on the JingPad, the other is on the Fairphone 4. JingPad users frequently ask for those tools and the Fairphone 4 also allows for a proper desktop setup, hence me seeing some usefulness there too.
I’ve started to take a look again and from all of the tested arm64 Snaps only Docker (Ubuntu Pastebin) and Cups seems to refuse operation/installation. But Chromium, GIMP (graphical artifacts from the screenshot don’t appear on-screen), Libreoffice, Hedgewars all start and operate pretty well. Some apps prefer X over Wayland at the moment but Hybris graphics integration is still an open issue that nobody has enlightened me on the preferred way of implementing yet.
Other than that we’ve got little shell issues like misplaced window contents hopefully fixed soon.
