Anbox will never be supported as a snap, remember it's a classic snap, not confined. It actually relies on the host being Ubuntu.
We'd need to package up the kernel modules (i.e. -current style split) and Anbox ourselves.
I think being able to run Android apps out of the box could be a killer feature on top of Budgie.
Unfortunately Anbox relies heavily on Ubuntu-specific tools, like classic snaps.
It is not even updated for the latest Ubuntu 18.04 LTS. https://github.com/anbox/anbox/issues/565
Packaging Anbox for Solus would probably require re-working some of the raw Anbox components, a task to be sure.
Because this feature is highly sought after though, and could help fill a lot of the desktop app shortfall on Linux, it's worth exploring.
Particularly since Chrome OS will now run Linux apps and Windows is shipping a Linux shell, I think being able to run Android apps would keep Linux competitive, take a bit from macOS.
I also expect to see a push to get Anbox running in the Ubuntu Touch project now run by UBports on the Librem 5.
Anbox can actually run on Solus (as in, it opens an empty window then crashes), it just needs the kernel modules required by Anbox itself (ashmem and binder) to fully work AFAIK. You can install the Anbox snap using the edge channel:
snap install --edge --devmode anbox
This is confirmed by what the lead developer on Anbox says here:
Ultimately every distribution would include the kernel modules in their archive so that users can install them out of the box and then just need the snap on top.
However I think for Solus it would make sense to then package everything in an eopkg, to avoid the classic snap issue.
It seems like a script could:
- Install basic building tools: git, cmake, kernel sources, via eopkg.
- Build and install the required kernel modules for Anbox. https://github.com/anbox/anbox/tree/master/kernel
- Install the build dependencies for Anbox listed in the snap package, via eopkg. https://github.com/anbox/anbox/blob/master/snapcraft.yaml
- Build anbox directly using cmake.
- Generate a .desktop file for end-users.
Provided all the dependencies are there and up to date. And there's not some other issue that's bound to appear.
Is eopkg in a place where it's worth attempting the above from within a eopkg file, or is script the way to go? I would appreciate some thoughts.
I have started work on the outlines of an install script for Solus.
So far I have run into some cmake issues.
I am working with Anbox developer over there in a thread too.
Also I have identified three dependencies that may need to built from scratch because they are not in the Solus repo currently.
I will need help with parts of the script building and install kernel modules.
I will also need help resolving these cmake issues and the three dependencies. They may become requests for packages down the line.
I do believe the speed of Solus is a killer feature, I think OOTB Android app support from Anbox would be a second killer feature. If we can make it work.
Instead of being forced to buy Google's Chrome OS with the option to run Linux apps, you can buy any x86 hardware, plus Solus on it, and have the option to run Android apps.
It would be a better, more secure, less corporate-dependent convergence of desktop and mobile apps.
@DataDrake can you re-evaluate this? Things changed and the modules required for Anbox are now available in kernel:
However if you don’t want these modules to be built-in for your kernel, there are patches, to build them as modules.
The anbox itself is available in snapstore: no need to package it.
The only issue is with the modules: they are not available yet in Solus built kernel. And there's no an easy way to get them working in Solus unfortunately.
@OEvgeny That's not why I rejected this. I rejected it because it requires shipping an entire android system image with Anbox in order for it to work out of the box. That introduces a whole host of security issues that we shouldn't be taking on with a team our size.
As far as the kernel drivers are concerned, I would rather not enable an entirely different memory allocator and IPC mechanism just so that people can emulate Android. Unlike enabling modules for hardware where there is little to no potential for security issues, these modules can open up much wider attack surfaces, and unlike native Android, we aren't running the services that Android would use to secure them.
Thank you DataDrake for the reply. These are good points and I really like that security is something Solus team is concerned about.
I'd like to note again though that there is an option to have these modules not to be built into the kernel rather have them built as a separate modules. Debian went this way. Solus may have a dedicated package to ship these modules which is not preinstalled by default (the same way as some drivers are shipping).
I understand the effort maintaining kernel patches and I'd rather not to ask this for some random thing. I think it's just worth to mention the opportunity. There might be some other ways in Solus to handle such cases I'm not aware of.
We aren't Debian. We purposely avoid enabling kernel modules unless they are absolutely needed for hardware or OS support. I can't emphasize enough that these aren't normal modules and they do increase the attack surface if they get loaded. Enabling them is the security equivalent of having a loaded gun in a locked cabinet. All someone needs is root access and then these modules become problematic.
Agree. Although, I don't see how non-existence of these modules built and packaged separately from the kernel limits the attack surface actually. With root access it's all possible: add a third-party repo, fetch and load-in prebuilt modules for a specific kernel.
@OEvgeny These are in-tree modules. We don't split them into separate packages.
There's more than one way to get root. Anbox needs to request these modules be loaded, but at least its capabilities can be limited and its behavior is expected. The rest of the time those modules are just sitting there for other things with root access to potential load. I'd rather not introduce that risk.