I was looking to switch my mobile to /e/OS which is self-described de-googled Android. Unfortunately I chose to order from Fairphone which has not arrived and I have given up for now, but I am still interested in moving away from reliance on US businesses (/e/OS can use French based Murena cloud). Which got me thinking about the possibility of Genode being used to replace the linux kernel and base services that runs /e/OS. Essentially a version of Sculpt with the necessary modifications to run the Android apps, possibly as a stopgap until native ones are developed.
This is exactly what Fuchsia, a very similar operating system to Genode, was expected to do within mainline Android. It is notable that they did not achieve this so far, having limited Fuchsia to replacing a few Homehub firmware.
I started a topic on the /e/OS forum to discuss the practicalities with that community, but I think the idea has merit. /e/OS has a modest user-base already, are quite tech savvy and happy to tolerate the rough edges of the present service. They also like their privacy which would be improved by moving /e/OS to Genode.
The main problem you’re likely to run into is that phones have mostly closed-source drivers. This will make the development of a compatibility shim for an L4 series microkernel (like Genode is a wrapper for) to be exceedingly difficult. Also, most de-Googled Android operating systems are forks of LineageOS (a Googled fork of Android for modernizing older phones without manufacturer intervention) because Android drivers are a pain, as are all drivers that are closed source.
In addition, while porting the Android ART VM to genode is listed as an interesting possibility on Genode - Future Challenges of the Genode project I don’t believe it’s been attempted yet. Without that, it would need to run an emulated Linux which loses many of the benefits.
I for one think the project would be cool, though for genode to succeed in mobile it would certainly also need native apps with features and guarantees that better supported android forks can’t provide, with traditional android apps being a fallback in the same way Linux VMs on desktop genode is a fallback.
L4Re might be able to run a hosted Linux kernel instead of an emulated one. The biggest problem is that microkernel drivers still have to run in user mode and communicate with the Linux host via interprocess communications. I’d still maintain that the IPC requirement for drivers, in addition to difficulty of porting, would also reduce the possibility of running a rogue driver containing a cargo of spyware in addition to its standard functionality.
The other participant on the thread on the /e/ forum seems to prefer the idea of Sculpt rather than using the Genode framework to invisibly replace the guts of Android!
I am starting to think that the cloud matters as much as, if not more so, than the actual library of apps available for the OS. As well as the obvious services like email and calendar, there is app store purchases, database of passwords, find my device, storage, payment services and all the rest of it. Whilst Sculpt Mobile is unlikely to be a first class citizen on Apple or Google cloud, an indy one like Murena ought to be happy to take us on.
Murena give away /e/ for free in the hope that they can sell users their mobile devices and cloud service, so another OS would be another string to their bow. In fact they ought be responsible for integrating Sculpt Mobile due to this added value it would bring to their business.
With anyone else’s cloud synchronisation across devices, we could all get Pinephones and use Sculpt Mobile whilst retaining an Android device to cover the missing features.
That sounds to me similar to how Apple’s XNU in Darwin is (was) BSD kernel on top of Mach microkernel, which seems to work well for them.
When I found out that the Sculpt operating system had a mobile version—both designed and actually implemented—I went ahead and built a Linux-based model to try it out. And honestly, I found it super interesting. The idea of having a system that you can truly control and manage yourself (not just “customizable” in name like most Linux distros) is seriously exciting.
The first question that popped into my head was:
How realistic is it to run Android apps on a system like this?
After doing some digging—and chatting with AI a bit—I ran into two challenges:
The way Android app services are built is so tightly connected to their own runtime and infrastructure that creating a proper interface between them and a completely different OS like Sculpt would mean writing 2 to 3 million lines of code.
On top of that, most of the hardware out there isn’t open source, so making this kind of setup work widely across different devices is pretty much impossible.
So, in the end, I think the best approach right now is the one taken by L4Android. It follows a dual-structure idea:
One part is fully native, minimal, and secure —basically the core OS.
The other part is a hypervisor-like layer that runs Android in a virtualized space.
But even this method is super time-consuming and full of challenges.
So in the end, I just decided to stop thinking about it for now
The lack of comprehensive end-to-end encryption makes Murena’s cloud services quite useless. I started writing a replacement for some of MicroG in Dart Native using Flutter as a UI and Citadel as a server-side for the services. For encryption I was going to use I2P protocol.
