Personal journal: The road to Halium with Ubuntu Core
Hello party people, I’m again wanting to share an idea that has been brewing on my personal list for a long time, and I wanted to give the challenge a shot. This is a personal challenge as of now, so bear with me, it’s not related to anybody’s project but at best those I’m involved in like Halium, contributions to libhybris, etc. Consider this an invitation into the discussion.
Android hardware
I also work on Halium in my spare time, which is the Hardware Abstraction Layer and has components for hardware integration for “All Things Android” devices, from phone to tablet to possibly TV boxes.
Over the years I have come across certain opinions and options of integration into an Ubuntu Core based system by now and I wanted to share my approach of enabling such functionality under solutions available under the umbrella of the Halium project (namely an implementation/distribution of libhybris, Android runtime adaptation support and more).
Halium in a nutshell
A regular Halium device, for example one running Ubuntu Touch, is doing the GNU/Linux dance by running a Generic Halium Image version matching the vendor partition available from the Android partition layout (/vendor and/or /odm in most cases). These two components (Generic Halium Image and vendor blob separation) allow us to effectively run a LXC container with some crucial privileges to enable the task of driving the hardware.
Then there are compatibility libraries for use in GNU/Linux userlands like Ubuntu, which effectively allow loading Android vendor modules like libEGL, OpenGL ES & Vulkan drivers, etc.
Additionally, depending on the Android device at hand, it might be necessary to patch up kernel sources and making them build and work. First hands-on experience with this has been made using the “sargo” device kernel for the Pixel 3a: lp:~beidl/+git/halium-b4s4-kernel-snap : Git : Code : Alfred E. Neumayer
Now how would that enablement in an all/“mostly all”-Snap scenario look like?
Halium Snaps to enable this would require to be split in a certain way and plugged together to achieve a uniform, predictable behavior across generations of Halium. Right now the PoC on my local machine looks like:
- The
haliumsnap: containing libhybris, LXC for driving (mostly stubbed) mini-Android services, some basic management services and provides support for anything explicitly requiring libhybris on a GNU/Linux userland as a content snap. -
halium9as the initial PoC target version for Android 9.0 based devices.
This would allow a pretty much Snap-only environment using only the smallest possible core in a regular rootfs (like a minified Ubuntu rootfs tarball) to be driven using a Snap-packaged Halium adaptation, allowing hardware enablement through the installation of 2 Snaps and plugging them together. The LXC container would run and provide full access to the sensor, hardware, modem and other capabilities.
For a really all-Snap environment though other things still need to happen like ubuntu-image respecting the partitioning of Android devices and spit out Fastboot-compatible images, TWRP zip flashables or whatever the cool kids use these days to accomplish alternative , deeper kernel Snap investigation and so forth, so I consider this out of scope for now. Additionally, newer Android devices follow the Generic Kernel Image model describing ABI compatibility between the kernel and the proprietary vendor modules. Enabling some crucial kernel switches for Ubuntu Core might turn out to be problematic due to risk of breaking kernel module ABI.
Right now I’m still at the planning phase figuring out how to provide a minimal rootfs (short term) showcasing the idea of running Snapped Halium. The individual snaps build locally but as far is I can tell the Snaps need to be available publicly which is hard to achieve right now, considering obstacles like kernel snap name registrations. Do Gadget Snaps make sense somewhere I’m not looking? I’ve got more questions. Anyhow, if anybody wants to provide input on the idea and/or has specific views on implementation details: Sharing opinions is very much welcome.
I specifically “don’t wanna dump this and never look at it again”, so it might need a name which I’m not really sure about yet, hence no public availability yet either…