Creating Snaps on Ubuntu Touch

by Aaron Prisk on 3 April 2024

This article was written in collaboration with Alfred E. Neumayer of the UBports Project.

Tablets, phones and current technology’s capabilities are phenomenal. Who would have thought a thin, light, barely 10 inch device would provide all the power necessary to run Virtual Machines, wherever one desires while powered on battery? That a smartphone would be able to power Linux containers for tough development workloads? Not me.

The ability to adapt to whatever the situation might require, the ability to provide the right input methods on the right device at the right time, as well as nuanced differences between the capabilities of multiple devices using the same design, look and feel. We call this convergence, and Ubuntu Touch as a mobile Operating System provides just that.

More than just a phone that docks into a multi-monitor setup with keyboard and mouse, and more than just a tablet connected to a keyboard case, this provides the ability to fluently move from one device to another while still feeling right at home.

But how could one satisfy the needs for both regular end users as well as those who want to push their devices to their limits?

Modern ideals for a mobile device

When tablets started to be geared towards the average consumer’s requirements instead of catering to power user’s needs, the ideals for a tablet shifted. Not only should there be a specific way of using it, the device would also chug along and do everything it can to let the user know: “I work properly fine, you don’t have to manage me.”

But does that count for developer needs as much as for video or music production, or playing games on a flat piece of glass in your hand?

Maybe it does. Let’s find out!

But why?

Advertisements exist around tablets that make them seem as if they were the next evolutionary step for Personal Computing devices, but a proper Personal Computing device needs to have the ability to host itself, in other words: Development for the device on that same device should be possible, to ensure its versatility.

Not only do self-hosting abilities allow for proving a philosophical point, it practically allows to enrich the FLOSS ecosystem on the go using a light and portable device, so what’s not to like about that?

Getting an Ubuntu-based tablet device

There are usually 3 types of ways to obtain a tablet device fully equipped with a supported version of Ubuntu, no matter the flavor:

– Installing one of the various Ubuntu flavors suited for the specific device

– Putting Ubuntu Touch on an off-the-shelf Android-powered ARM device using the UBports Installer

– Running Ubuntu Touch on a mainline device with familiar FLOSS hardware integration stacks

Should the UBports Installer not support it already, an Android-powered device might need a device adaptation (also called a “Port”) based on Halium or similar. The UBports Community has various channels for getting help along the way, should one desire to bring Ubuntu Touch to live on their device. For more information visit: https://ubports.com/en/members/contributors/porting-21

Running Snaps on Ubuntu Touch

This is still experimental which is explained by the immutable-by-default file system requiring a read-write remount, which Ubuntu Touch doesn’t officially give support for. Shipping `snapd` by default will take some time to fully bake but it’ll be worth the wait.

For those eager to give Snap support a shot: have a look at Snapz0r and enable Snap support on your Ubuntu Touch device based on 20.04.

In the case you dramatically break the installation, it is still very simple to just reflash the device using the UBports Installer with “Data Wipe” checked off to keep your private data around.

So, assuming one has `snapd` installed on their Ubuntu Touch device and rebooted once, one should be immediately able to do regular Snap things like installing and managing them, even without the need for sudo powers!

Steps to Snapcraft

Setting up Snapcraft for developing with such a device requires a little bit more hand-holding than usual, but it certainly is doable. It requires setting up a privileged LXD container at first, then running `snapcraft` in Destructive Mode. Remember that a base OS in the container closely matching the target core Snap improves the chances of success.

sudo snap install lxd

sudo lxd init

sudo lxd launch ubuntu:22.04 snapcraft-jammy

This sets up a container that may or may not fail to launch. In order to give it (potentially dangerous) capabilities during the use of the container, you’ll have to elevate privileges:

sudo lxc config set snapcraft-jammy security.privileged=true

sudo lxc start snapcraft-jammy

Next, in order to access your projects directory you surely want them to be mounted into the container, assuming you are running Ubuntu Touch with projects stored in a directory called `Projects` inside of your home directory:

sudo lxc config device add snapcraft-jammy projects disk source=/home/phablet/Projects path=/home/ubuntu/Projects

Build using Snapcraft

With your container set up neatly you should have access to all tools necessary to accomplish your goal of Snapcrafting.

sudo lxc shell snapcraft-jammy

snap install snapcraft

Off we go! Cloning and entering a repository with an additional last

snapcraft --destructive-mode

command and you should get you to where you need to be.

Where do we go from here?

The quest for more apps on Ubuntu Touch is still ongoing as is the necessity to provide Desktop applications to more capable devices. Phones and tablets with the ability to connect a secondary monitor provide good circumstances to be productive both on the go as well as stationary with the right tools at hand. Right now, Ubuntu Touch ships two solutions:

– Click packages

– Libertine

Clicks are tightly integrated into the system, providing everything a modern packaging format needs to provide on a smartphone or tablet device. They target the frameworks shipped with a regular Ubuntu Touch release or allow shipping dependencies themselves, with a permission system for security management. With services around Click integrating perfectly this turns apps into something users can easily pass data around with (a little reminiscent of good old command line pipes) while still providing expected security.

Libertine on the other hand is meant for installing regular .deb packages in a chroot or container which looks much like a traditional system rather than an immutable one like Ubuntu Touch. This is a stop gap solution for tinkerers and an additional ground of exploration on Desktop-only or otherwise unoptimized software.

The spiritual successor

Clicks were a precursor to Snaps in the sense that they both rely on AppArmor and certain other kernel features present, running on immutable file systems as well, so it makes sense to reach for the stars by implementing Snap support as an installation option. Not only do Snaps provide everything expected from a modern-day packaging format for consumer electronics, it also has a flexible permission system through slots, plugs and their interfaces.

The hurdles

The immutable file system, AppArmor as a requirement for official device ports as well as other kernel features provide a good base for what a mobile Operating System with Snap support can look like, but the hardware integration might seem foreign to a regular GNU/Linux stack. There is [Halium](https://halium.org) as an integration of Android drivers into a GNU/Linux system. This is accomplished by a LXC container providing Hardware Abstraction Layer (HAL) services for various tasks like sensor management, modem connection and other reasons. Furthermore, does that complicate things at a permission level? But fret not, change is on the horizon.

The approach

Several things are in motion to get `snapd` to work beautifully.

– Enabling Android driver support by passing on the host system’s libhybris drivers is one such task being worked on.

– The “selective writable paths” solution for making certain paths write-accessible needs changes to accommodate for feature completeness.

– Additionally the daemon needs to treat the immutable-but-classic file system layout in a way appropriate for Ubuntu Touch, from extrauser to other areas where expectations differ.

– Integration of default Ubuntu Touch services with access to Media-Hub, Location Services and others needs to be on feature parity with Clicks, together with Content-Hub integration.

These are just a few areas worth noting, with whatever the exploration of the dark voids of the unknown will show next!

Join the mobile movement

To learn more about Ubuntu Touch and discover how you can get involved, please visit: https://ubports.com/