Why Is It So Difficult To Build an Alternative Operating System for a Smartphone?
This post was last edited 35 minutes ago.
Recently, someone sent me "Will Linux phones become a viable alternative to the Android/iOS duopoly?" by Amos B. Batto, an interesting technical blogger who does deep dives into topics ranging from e-bike legislation to alternative mobile phone systems.
As I began to read, I realised how little I know about smartphones and their related jargon and acronyms.
I've been experimenting with alternative mobile operating systems for years—my family members have either /e/OS, a Linux variant, or GrapheneOS and I use the latter myself as my daily driver—and I did that by following online guides, or using easy installers, where available.
I did, however, have the awareness that developers of these alternative systems seem to always be fighting against the current. My own experiences with Linux operating systems taught me that it is not straightforward to get something like a phone's a camera to work properly on an alternative system, but up until recently, I never understood why that is the case.
I began a deep dive into Android-related jargon, acronyms and general concepts. I used Lumo AI to help me learn about how both the hardware and software of mobile phone systems work, and why developers of alternative systems have such an uphill battle to fight.
Below is a summary of what I've learned so far. Writing the article was a way to test my own knowledge, but, hopefully, it can also be a useful starting point for someone new to alternative smartphone systems; and perhaps it might fill in some knowledge gaps for those already familiar with the topic.
The hardware
The problems start here, and it's a fascinating story. Two weeks ago, my son asked me why it's so easy to run a Linux distro on just about any computer, and yet it's so hard to do that on a mobile phone. My answer at the time was that it's probably to do with three or more decades of Linux development on laptops, PCs and other types of computers, while mobile hardware is more recent. That is partly true, but not entirely correct.
A PC or laptop is a relatively open piece of hardware, whereas phone manufacturers hide how the hardware works from users, developers...anyone but the manufacturers themselves. This is what makes writing software for smartphones difficult: it's a partially obfuscated system.
This brings me to the first set of terms, namely proprietary versus open source. These terms can apply to both hardware and software.
Proprietary means 'owned by someone'. In most cases, that also means 'closed' and 'hidden'.
In hardware, open source means that the inner workings of hardware are transparent by design. For example, some companies publish the schematics for the electronic devices you own, while others make your 'right to repair' an impossibility by hiding that information.
I want to keep the focus on hardware for the moment, but will cover the topic of open source software further down.
The companies involved in making the hardware are the chip vendors who make deals with OEMs, or Original Equipment Manufacturers. Samsung, Google, Apple, these are all examples of companies that work with the different hardware component companies to design, produce and sell the final product: the phone that's likely in your hand or pocket right now. Google is the OEM; Qualcomm is the chip company.
The deals between the OEMs and the hardware component vendors are usually closed contracts with non-disclosure agreements. While Google's engineers know how the latest phone chip works or at least how to write software that can talk it, they are not allowed to share that knowledge with outsiders. This becomes important later, when we talk about upstreaming knowledge and code to the Linux kernel.
The chips in your phones are called SoCs, which stands for System on Chip. The CPU (computing power), the GPU(graphics), the power manager and other elements are all integrated into one silicon chip. This makes it harder to examine what each element is doing and how it works. This is different from a laptop or PC, which has more room inside, and where each part has its own space on the motherboard, and can often be removed, cleaned or replaced.
Qualcomm is a vendor that makes and sell commonly used SoCs called Snapdragon chips. The software required to operate the elements on those chips is hidden from the public.
There are elements, such as the WiFi card, the audio elements and the RAM (working memory) that are still on separate chips, though over time more and more of these get integrated into the SoC.
Hardware elements require drivers and firmware. These are specific bits of code that tell the Android system how to, for example, use the physical camera. This firmware is part of the non-disclosure agreement and there are some bits of code on the hardware that not even Google can see; they only know how to communicate with it.
To sum up, the hardware inside your phone is compact and the knowledge of how key parts work is proprietary and closed source. These are major hurdles to overcome for developers trying to make an alternative operating system for mobile.
What happens when you turn on your Android phone
When you press the power button, the hidden software that's burnt into the chips themselves by their vendors activates and this sets a chain of events in motion. This is called the Boot ROM and it is baked into the System on Chip.
The other software elements listed below exist on something called flash memory and wait to be activated. When the battery on your phone runs out, flash memory is still able to store this software.
The bootloader is a software system on the flash memory of your phone that checks if you are allowed to go further. If there is anything unexpected, like malware or an alternative operating system, a locked bootloader won't allow you to continue. The bootloader also continues the process of waking up the phone and it sends software to the RAM, which is the working memory when a device is powered on. RAM stands for random-access memory.
Next, Google's own version of the Linux kernel, which also lives on the flash memory, starts up and sees what type of hardware its dealing with through something called a device tree, a file that contains a description of all the specific hardware elements on your phone. The kernel then activates all the firmware and drivers required to run the different elements of the phone and sends firmware to the elements that are outside the SoC, such as the camera and the Wi-Fi chip.
Next we get to a layer with a distinct science fiction vibe: HAL and vendor blobs.
HAL stands for the Hardware Abstraction Layer. This is a middle layer of software that allows the operating system (Android or something else) and the apps to communicate with the firmware, which in turn know how to operate the specific hardware elements—the camera, the microphone, the modem—in your phone.
Blobs are crucial bits of code whose inner workings are hidden from view (hence 'blob') yet essential to make the phone work. Google stores these in your Android userspace, the bit you see and interact with, for very sneaky reasons which we'll look at further down. The blobs are called by the boot up sequence, and once activated, then all the hardware in the phone will work.
Finally the operating system is what you interact with and what helps you manage your home screen and your apps. The operating system is the userspace and when you buy a non-iPhone device, that userspace is Google's Android.
The bootloader and the fact several of the above software stages are not open source make it very challenging for alternative operating system developers to get their software to take full advantage of the hardware on the phone, which can result in a sub-par user experience.
Unlocking and re-locking your phone
When you try to install an alternative software operating system, the bootloader first needs to be unlocked, as otherwise it will not allow a foreign system to run on your phone.
Fewer and fewer phone companies are allowing users to unlock the bootloader on their phones. You used to be able to go to the manufacturer's website and register your phone there, and receive a code or method for unlocking the bootloader a day later. It is less likely today that your phone company will allow that, though some still do. On the other hand, a handful of companies, like Fairphone, and newcomer Nexphone allow users to open the bootloader on their devices by design, encouraging the installation of other operating systems.
Ironically, Google's Pixel phones are still easy to unlock. What's more, you can re-lock the bootloader on a Pixel after installing alternative software on it, which is crucial for security. This is why GrapheneOS, an alternative Android-based operating system focused mainly on security, only works on Pixels for now (though a deal with Samsung is in the works).
Phones that have such Android derivates can sometimes be locked again, but phones that have Linux operating systems can't, because there is no Android left to work with.
The fact that many phones cannot be unlocked, and that even fewer vendors allow re-locking of hardware is a major hurdle in creating an alternative system that is both private and secure.
Free and open source software
On the software side of things, FOSS, or free and open source software is free for anyone to take, modify and redistribute, depending on the type of license it comes under.
Free here means there is no cost, but also free to use as you wish, within the boundaries of the given license.
Open source software has the advantage that it is public and can have many eyes on it, which in theory should make it harder to sneak bad or malicious software into it. To me, open source software, with its many volunteers, is one of the wonders of the Internet.
For more on this, see The Open Source Definition (Annotated). You'll see further down that even Google takes advantage of this free distribution model, and is allowed to do so.
We need to understand the distinction between close and open source software in order to see how Google both takes advantage of FOSS yet at the same time controls the software they produce themselves.
What is the Linux kernel?
The Linux kernel is a massive open source software project that goes back decades. Linus Torvalds oversees the project, and he has designed clever tools and a system that enable lots of different individuals and groups to contribute improvements to it.
Much of the Internet today operates on Linux. Linux runs on computers and servers, laptops, phones, game consoles, refrigerators and other Internet of Things devices. Linux is an operating system that makes the world go round.
Additions and improvements to the kernel are submitted upstream to the Linux kernel. When a developer or company successfully upstreams code to the kernel, it is maintained by the community from that point on, taking the responsibility off their hands, so this is the holy grail for developers.
Let's say you've designed open source software that runs on a specific type of doorbell camera, based on the Linux kernel. With each new update of the kernel, you might have to make adjustments, or patches to your code so that your camera software continues to work. However, if you are able to successfully submit your code to the Linux kernel, then maintaining that software become the community's responsibility.
The further downstream your project is, the more work you have on your hands to keep up with changes in the kernel, so moving your bit of code upstream is the key to success when working with Linux.
The Linux kernel is open source and published under a GPL license. The agreement here is that others can take the software and use it, even to make money, as long as all they keep the code open source too.
Companies like Google take advantage of the work done on upstream Linux kernel, but then bring the version they use on their devices downstream to a place they can control a bit more. This makes it harder for other developers to get the updates they need to build working alternative mobile systems. While these developers can request the kernel code because it still falls under the open license, the for-profit companies can drag their feet and frustrate development process.
What is the Android Open Source Project?
The userspace is the name for the Android operating system we interact with when we buy an Android phone. Google bought Android and now controls its development and how much information is made public with the AOSP, the Android Open Source Project.
As the name suggests, this is also an open source project, but under a different license that allows greater company control. Most of the development on Android happens behind closed doors. Google employs a team of engineers to work on AOSP, and publishes the result to the world.1
For-profit companies that have deals with Google can get early access to this behind-the-scenes development, so they can prepare their devices or software for Android updates accordingly.
AOSP is published by Google and can then be used by free, alternative Android-based systems like GrapheneOS, but this is always at the behest of Google; Google is under no obligation to continue sharing their work and they can, and have, changed the rate of publication.
Why blobs are in the userspace
One of the harsh realities for people interested in open source projects is that, while OEMs like Google take advantage of the kernel, they will withhold specific proprietary information about devices, chips and firmware. This makes sense from a business point of view, but doesn't sit well with the spirit of open source.
So how do OEMs hide these crucial elements and yet still make phones work? The developers at these companies create what are referred to as blobs: obfuscated bits of firmware and code essential to the operation of your phone. These blobs are stored in the Android userspace, and called into action when the phone starts up.
So a vendor-locked phone, containing a 'frozen' downstream version of the Linux kernel at its base and with Android running on top of that is fully usable, but any open source developer trying to build an alternative operating system for that phone will not be able to see how certain key parts work, because the code for those hardware elements is obfuscated in blobs, which are placed outside the kernel in the userspace. Open source in name, not in spirit.
Reverse engineering, the Google Pixel 3A(XL) and the Fairphone 5
Communities interested in more open and transparent models can work together to reverse engineer hardware, one chip at a time. This process is far beyond me, but from what I understand, it involves close observation of how a chip acts and reacts to different commands and then drawing conclusions about its inner workings from that. The people that do this type of work seem like magicians to me.
As a result of community reverse engineering work, some Systems on Chip are partially or nearly wholly discovered and this knowledge is then upstreamed to the Linux kernel.
The reason so many alternative systems will run quite well on the older Google Pixel 3A(or XL) phone is because a lot of work has been done by the community to reverse engineer its Qualcomm SDM670 chip. Most projects I know of will work well on this phone, so it's a good one to look out for secondhand if you are someone who is interested in experimenting with alternative operating systems.
The Fairphone 5 with its Qualcomm QCM6490 chip is another example of a phone that multiple alternative systems can work quite well on.
Some alternative mobile phone systems groups aim to get their software to work on as many devices as possible, so many people can access their operation system and older devices can be given a second life. The flip-side here is that, while there may be versions, or ports, of a Linux operating system like Nura (previously PostmarketOS) for my old Moto G6 plus, the camera and audio elements don't work. These projects are in experimental development phase, and in some cases, are at a dead end, because the community isn't going to be investing further in reverse-engineering chips that are on these devices.
There are several companies offering alternative mobile phones and operating systems, but it is important to look at whether a)the hardware stands a chance of getting community reverse engineering support, and b) the companies themselves are willing to pass device trees and other crucial code upstream to the Linux kernel. If either of these are not the case, then these projects can be a bit dead in the water, with a view to developing a true alternative Linux phone in the future.
The most interesting and relevant projects, therefore, are those where there is a concerted effort to upstream as much information about a certain phone and its chips to the mainline Linux kernel, so all future projects can benefit. In a future post in this series, I'll explore which projects those are, and why, like Amos B. Batto, whose article I began this long post with, I feel hopeful about a future for Linux phones.
Looking ahead: a series on alternative mobile phone systems
This was the first of a series of articles I plan to write about this topic. I would like to explore specific alternative mobile operating systems as well as current hardware projects. I also want to look at how to flash stock Android onto a Pixel phone, which is often a required prerequisite for installing an alternative operating system.
The person who sent me the Amos B. Batto article is Kieran, someone who is also interested in Linux and alternative mobile systems. He recently purchased a Jolla phone, made by a Finish company, and he has kindly agreed to write an in-depth review of his experiences with it and its operating system, SailfishOS.
I hope to write about my own experiences using GrapheneOS and why it is our current best bet for banking and government ID apps, and I want to conclude with an overview of the most promising hardware and software Linux phone combinations currently available to us.
Note on the process of learning
I have recently started using Lumo AI by Proton. I've thusfar been very cautious about using AI chatbots, but I feel I can trust Proton, which is based in Switzerland, to keep my conversations with Lumo private.
Much of my learning about mobile phones over the past weeks was done on Lumo. I would query each term or acronym in the Amos B. Batto article instead of glossing over them, which is what I would normally do. Each query led me down interesting, late-night rabbit holes about specific concepts related to Android, mobile phone hardware, and Linux.
I took some notes during the process and occasionally asked Lumo to sum up key comparisons into charts. Some of these charts were good, some were terrible.
I wrote most of the above from memory, occasionally consultating my notes, the Lumo conversation threads and additional online searches. I'm not good at remembering what acronyms stand for. Nothing in the article above was copied and pasted.
After two weeks of intensive learning, I felt like I'd completed a whole course on the subject, but I wasn't confident about my retention of the new knowledge, so I wrote this article to consolidate my own learning, kind of like an end-of-term essay.
Of course there will be errors in my learning and the summary above. I will try to make adaptations as and when I receive such feedback.
I want to thank these people for taking the time to read draft versions of this article and sending me helpful feedback: Bruno (Uruky, Henry (Techlore, Kieran, HM, Michael, IG.
Documentation
"Will Linux phones become a viable alternative to the Android/iOS duopoly?" by Amos B. Batto
The Open Source Definition (Annotated)
-----Discuss on Mastodon-----
Find me on Mastodon.
Google develops Android mostly under an Apache 2.0 licence, which is what allows them and other manufacturers to introduce changes to the software and freeze their version of Android for specific devices without any obligation to upstream or publish those changes. Google publishes AOSP code voluntarily and is not obliged to do so. It is therefore in control of how often and how much it shares this code. In 2026 Google decided to reduce their publication cycle from quarterly to just two times a year. They also stopped including device trees in Android at some point, making alternative software development that much harder.↩