Draft: Something called "Snapium"

device
1

Hear me out…

I am often representing with my Ubuntu Touch hat on in here, but this is more of a Halium-related topic. I want to start this discussion to fill some blanks and have a clear idea forward. Now bear with me.

On Ubuntu Touch we use something called Halium to make porting of Ubuntu to Android-based devices easy.

Something similar to this in the Snap realms would be cool.

I’ve formed opinions about feasibility of making an Ubuntu Core type of environment work with Android devices or Halium adaptations. There are some things we’re able to get away with on Ubuntu Touch that simply aren’t supposed to work in Ubuntu Core:

  • Overlay device-specific files on top of the rootfs at runtime
  • Ubuntu Touch follows the Android partitioning scheme
  • Ubuntu Core enforces its own, incompatible partitioning scheme
  • Reusing Android’s /vendor partition inside a confined snap environment?

There are more questions but these are enough for now.

On Touch we use a generic rootfs while the port maintainer ships files to overlay on top of the rootfs at boot & runtime. I cannot imagine a clear way to do this with Snaps at the moment.

For things like PulseAudio support we often rely on modules-droid compiled against the exact Audio HAL API of that /vendor partition. On Touch we ship them all and have the port maintainer specify the appropriate one as another Halium file overlay when defaults don’t suffice.

Regarding partitioning schemes: Since Android 9 we use something called “Binderized HALs” and rely on static partitions of the required Android generation to provide these + all required libraries in /vendor. These HALs run as processes inside of a LXC container, libs can be loaded by the host through libhybris.

I have no clear idea how to approach libhybris in a feasible way here. Shoutout if you have an idea.

In the end I aim at making a bootable “Halium-ified Snap” environment installable with regular Android partition tools like fastboot. This would also mean the initramfs to be different from the Ubuntu Core one, since Halium requirements can dramatically differ from device to device.

Thank you!

3 Likes
2

There is project Waydro.id for running apps on top of Ubuntu. There is Mobian for running Debian on top of phones with intent for merge all to core Debian and abandon itself.

There is movement like ubports with a lot of phones being abandoned after a few releases due lost kernel and drivers development, national telecommunications stacks compatibility not even tried as required and make functional with proper national stacks licensing.

Projects like Waydroid probably does some wrapping arround HAL but don’t know if ubport version is upgradable with lost drivers as described in ubport HAL docs…

For Samsung phones without fastboot there is unofficial Heimdall for flashing Samsung firmware but with a lot of issues and Samsung is not saying anything about Heimdall for Samsung soft, they have own Windows software…

And Waydroid as project is a fat stack with security blackholes nightmares and Android as fat stack only support this but maybe is Google doing something with Rust to improve performance and a native Vulkan performance, but this could last a eternity to implement if they desire so and not to use some Fuchsia or other probably disaster like current solution so time will tell…

For your question: if phone vendors have market and implement drivers for Linux is costly and logistics and sales ineffective to have such Ubuntu Touch/Debian phone, they could make some contractors or specialized company to offer their services to sustain kernel development and make possibility for such vendors to deliver their Android phones to corporations or users and make their approved phones a Ubuntu Touch/Debian reality with some installer.

But problem is that Android apps are today must have and also such corporations don’t make joint venture to such kernel implementation a donation reality and find someone to do so, so further Mobian movement could happen practically a Ubuntu Touch better reality without such HAL disaster after a few kernel version(and phone vendors firmware without maintainability like for Samsung firmware is doing some sites) or even are other commercial sites for other Android phones in which you connect your phone and it says it could upgrade your phone or not.

If Google thinks that HAL is a good idea without such fatness on PCs, then its emulator things could be made something into and wrapped into some cow2 or other foolness(like qemu, virtio Windows Red Hat drivers even on lxd but that should behave differently my humble opinion), because today reality is not having to run full Android when is not required, but maybe have desk with cable connected to PCs and phone on it without wifi and run on PC some app from Android on Linux desktop without emulation and on wide PC screen as TV app mode…

But that does not solve your problem and may be further to ask how to progress on this Android upgrade or driver shit.

And why I say virtio windows Red Hat drivers? Because some people try(and successfully) to run Windows 11 on Android :slight_smile: , so running Android apps on Linux Desktop is a bad idea as Google may think a lot if any in that ecosystem space ever have tried :slight_smile:

3

Nothing from Waydroid to mentioning Samsung phones made sense to me as sticking to the topic. What I mean is something very different.

First off: I know the Ubuntu Touch architecture and very well, I work on it. Secondly: I want this, I just ask technical questions and want a way forward.

This is about a Ubuntu Core-esque setup specifically for Android devices with as-little-modified-as-possible Android kernels, following whatever-generation Android’s bootup sequence with their partitioning scheme, LVM-like super partition and A/B boot already in the (often proprietary) bootloaders. Not about Waydroid.

Now, one way of achieving this would be by adding changes to initramfs-ubuntu-core which may or may not be based on unpopular decisions made by a 3rd party.

1 Like
4

Thinking out loud, and to potentially fill the image and make it clearer, I have a rough idea on how I would like to implement something like this:

  • Make a snapium-initramfs consisting of Halium bits getting the userdata LVM as a step before the ubuntu-core initramfs
  • Boot regular ubuntu-core initramfs bits since those seem to be invokable from regular debian initramfs archives
  • Ship that to a device and have it potentially operate outside of the Snap Store until possible otherwise.

I know there is an androidboot functionality in snapd but it mostly looks stubbed to me. At least I know it is not up to the functionality of recent Android bootloaders and hardware. Sadly, on these devices one better follows the possibilities of upstream Android hardware configurations.

Thing is that userdata LVM partitions are not a regular thing so I would propose a recovery similar to one UBports Ubuntu Touch uses (graphical, maybe .png’s involved).

All of this with a big “I am aware I’ll probably do this alone for some time” disclaimer.

So imagine an Android tablet reused as a smart home appliance stuck on your wall, one will want this to work properly.

You may either think I have bigger plans or want to waste some time on something cool, either way you can probably tell I am eager to get this done.

1 Like
5

To those who have seen this message and my talk about Ubuntu Touch with Snaps during the Ubuntu Summit 2024, but haven’t connected the dots yet: This is what I was talking about during my last slide.

So the idea would be to bootstrap the All-Snap capable environment just before the Core initramfs is reached, for a lack of a better phrase to just mount Android partitions, do kernel module loading and everything that pertains to non-Snappable components like vendor blobs.

I hope the talk gets published soon for the bigger picture to make sense on a technical level.

6

It sounds exciting! Exactly the kind of thing that demonstrates and pushes snapd capabilities. Let us know if (when!) the slides are public :slight_smile:

7

The slides are available at the bottom here, as Google Slides or a PDF: Ubuntu Summit 2024 (25-27 October 2024): What's going on with Snaps on Ubuntu Touch? · Canonical / Ubuntu Events (Indico)

8

I’ve had a read through and it’s nice to see Android community development flourishing, and of course snap too.

I used to tinker around with Cyanogenmod and the like back in the early days of Android, back when there was more to gain (simple stuff even, like screenshots not existing until Android 4? Or maybe 3 but we skipped that one), and when stuff like SafetyNet wasn’t as essential for stuff like banking. I’ve not unlocked my Androids since about 2015 since there’s less necessity and actually outright hostility from some developers.

But stuff like this, well, maybe when I get a new phone, I’ll keep the old one, being a Pixel, I’d actually like to try it out and imagine I’d have a good chance to. Unfortunately, beng a Pixel 9… I might be waiting a while. Fortunately, that’s 2 more years of progress and I hope it keeps going well!

It’s a shame there isn’t a bit more context on some of the slides (e.g the ones showing the patched source with the capability checks) because there’s obviously a hell of a lot that goes into this and that’s literally barely scratching the surface. But overall, it’s a nice read!