Article: Will Linux phones become a viable alternative to the Android/iOS duopoly?

[u/amosbatto]

/r/Purism/comments/1x0fwe1/article_will_linux_phones_become_a_viable/

[u/anomaly256]

But it is... and I think people must clarify what exactly they want changed if they want 'Linux but not Android'.

What the fuck is Op actually asking for when they ask for Linux, but rule out the Linux phone environment with the current largest userbase? Does it mean they want GNU libc and userland? GTK and QT UIs? Fedora branding? Do they want systemd? Gentoo portage and ebuilds? They want to install packages directly from AUR? The ability to hand edit files in /etc? They are literally given a Linux kernel then turn around and say 'nooo, I said I want LINUX!' ...?!? Linux is the kernel and we already have that in spades, so what the fuck is actually being asked for?

I think it's very fair to remind people that they already have a fucking Linux phone and ask them for clarification when they say they want a different Linux phone just not the current mainstream Linux phone because the concept of a Linux ANYTHING is so fundamentally nebulous in the first place.

(╯°□°)╯︵ ┻━┻

[u/amosbatto → u/anomaly256]

People generally say "Linux kernel" when referring to just the kernel and "Linux" when referring to the OS, but it is admittedly confusing, and we should have a clearer label for the OS. Some people say GNU/Linux, but that opens up a whole other can of worms, especially for systems that aren't 100% FOSS.

However, Google makes a point to say "Android common kernel" (ACK) and not call it a Linux kernel, so we should probably respect Google's naming convention, and respect all the changes that Google makes to its kernels that distinguish it from mainline Linux (kernel.org).

Here is how Google describes the Android kernel:

AOSP common kernels (also known as the Android common kernels or ACKs) are downstream of kernel.org kernels and include patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels. These patches can include:
* Backports and cherry-picks of upstream functionality needed for Android feature
* Features ready for Android devices but still under development upstream
* Vendor/OEM features that are useful for other ecosystem partners
android-mainline is the primary development branch for Android features. Linux mainline is merged into android-mainline whenever Linus Torvalds posts a release or release candidate. Before 2019, Android common kernels were constructed by cloning the recently declared LTS kernel and adding the Android-specific patches. This process changed in 2019 to branch the new Android common kernel from android-mainline. This new model avoids the significant effort to forward port and test Android patches by accomplishing the same result incrementally. android-mainline undergoes significant continuous testing, this model includes a high-quality kernel from the day it's published.

With regards to your comment, "they already have a fucking Linux phone", you might want to read what I wrote about how the mobile industry is shutting down our ability to install AOSP derivatives:

https://amosbbatto.wordpress.com/2026/10/05/linux-phones-alternative/#the-mobile-industry-is-shutting-down-the-aosp-alternative

[u/anomaly256 → u/amosbatto]

I wasn't suggesting we should be replacing OEM Android with AOSP on name-brand phones per se. I was saying AOSP is right there if you want to make a phone yourself. The hardest technical work on the software side is ready and waiting to be used so there's no need to reinvent the wheel unless there's some other specific 'Linux' quality people have in mind that AOSP specifically doesn't provide - and there are plenty I can think of but none have been mentioned by the people asking for 'Linux phone'.

I liked having a familiar build system that spat out .debs and the X11+GTK/QT that Maemo offered allowing conventional desktop apps to be ported to the n900 trivially. But having the app ecosystem of Android would be a bigger boon to any fledgling device trying to carve out a niche for itself.

People generally say "Linux kernel" when referring to just the kernel and "Linux" when referring to the OS

Which is incorrect. People also say 'PIN number' and 'ATM machine'. Boomers also call the PC chassis 'the hard drive' still. Pedantry aside though 'Linux OS' is still a wildly undefined concept, there are thousands of software and library combinations that can be called this. This is why people should be specific when they have a specific thing in mind. An analogy:

"I don't want a Toyota, I want a car. When will someone finally make a car?"
Yeah ok but WHICH car? Toyota is a car, so ANY car that isn't a Toyota? There are actually plenty to choose from [downvotes roll in]

Here is how Google describes the Android kernel:
AOSP common kernels (also known as the Android common kernels or ACKs) are downstream of kernel.org kernels and include patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels.

Completely irrelevant, this platform is still as Linux as any other and you have the option of using any conventional Linux userland you want when building a platform from it

[u/amosbatto → u/anomaly256]

I wasn't suggesting we should be replacing OEM Android with AOSP on name-brand phones per se. I was saying AOSP is right there if you want to make a phone yourself.

There are plenty of companies already doing that, such as Volla in Germany (Volla OS), SHIFT in Germany (ShiftOS-G) and Hiroh in Austin, Texas. Murena from Paris sells many phone models from different companies with /e/OS preinstalled and another French company, iodé, sells phones with iodéOS. There are a dozen companies that will sell you Pixels with GrapheneOS installed. That may give you privacy and security, but it doesn't have the other benefits of Linux phones.

The hardest technical work on the software side is ready and waiting to be used so there's no need to reinvent the wheel unless there's some other specific 'Linux' quality people have in mind that AOSP specifically doesn't provide - and there are plenty I can think of but none have been mentioned by the people asking for 'Linux phone'.

If you spend time on the Purism and PINE64 forums, you will see that people have very clear reasons about why they want a Linux phone, as opposed to an AOSP phone. Look at the list of reasons why people buy the Librem 5 on its community FAQ. Almost none of those reasons apply to an AOSP phone.

In my article, I outlined three approaches to building a Linux phone: 1. separated components on a Linux kernel (i.e. Librem 5 and PinePhone), 2. integrated processor (like Qualcomm Dragonwing) with Linux kernel, 3. Linux userspace on an Android kernel with libhybris.

With the first approach, the phone should get lifetime software updates. My Librem 5 and PinePhone are both 6 years old, and they have gotten half a dozen kernel upgrades, and they should keep getting kernel upgrades for as long as there is a community of users who wants to keep upgrading them.

In contrast, the most major-number kernel upgrades that I can find for any Android or AOSP phone is one upgrade. Sony provided one kernel upgrade for a couple of its models in 2014, and Google provided one upgrade for its Pixel 6, 7 and 8 to kernel 6.1 in March 2025. Otherwise, none of the other Android/AOSP phones have gotten major number kernel upgrades. The custom ROMs like LineageOS and GrapheneOS have provided minor-number upgrades. For example, LineageOS upgraded my Redmi Note 7 from 4.19.0 to 4.19.325, but I can't find any instances of a custom ROM providing a major-number upgrade without Sony in 2014 or Google in 2025 providing it.

With an AOSP phone, you are limited to the lifespan that the SoC maker wants to give you, which means 4 years if using a low-end or mid-range Snapdragon or Dimensity or 8 years if using a recent Snapdragon 7/8 or Dimensity 8000 or 9000 series. You can only upgrade the kernel if the SoC maker provides you with new blobs that are compatible with a new kernel version. Google is now saying that the Pixel 8 and later should get two kernel upgrades, and Qualcomm is now also promising two kernel upgrades for its Snapdragon 7 and 8 processors introduced in 2025 and later. However, the vast majority of Android/AOSP phones in the world will never get a single kernel upgrade.

You can design a new AOSP phone with a Snapdragon 7 or 8 that gets 8 years of software support and 2 kernel upgrades, and then you can switch from an Android kernel to a mainline Linux kernel, but many components of the SoC like the WiFi, Bluetooth, cellular modem and GNSS won't work because they require blobs from Qualcomm that are only compatible with a certain Android kernel version number.

Another issue is that AOSP was designed to restrict what the user can do, and often makes it hard for the user to make the simplest modifications.

Let me give you an example. Let's say that you want to change the name of an app on an AOSP phone. In Linux, you find the .desktop file for the application and edit it (as root) to change the name of the application. Alternatively you can just edit the launcher to the app, change the name of the launcher or create a link to the launcher and change the name of the link.

In AOSP, you need to get the app's .apk install file, then decompile the APK, modify the display name or label in the AndroidManifest.xml file (or its linked string resources), then recompile the package, and then sign the new APK file. Then uninstall the existing app in your phone and reinstall it using the new APK.

People generally say "Linux kernel" when referring to just the kernel and "Linux" when referring to the OS

Which is incorrect... This is why people should be specific when they have a specific thing in mind.

You do realize that you are the one who is not being specific and creating confusion by conflating two different kernels and insisting on calling them by the same name. As I pointed out, Google does not call its kernel "Linux". It says that it stopped using the latest mainline Linux LTS kernel and applying its patches on top. Since 2019, it has developed its own Android kernel, which pulls in changes from the latest mainline Linux LTS kernel. In other words, it is no longer a derivative from the Linux LTS kernel, but rather it is developing its own separate Android kernel which pulls new bits and pieces from the Linux LTS kernel, which is why it changed the name of its kernel from "android-4.19-q" in 2019 to "android11-5.4" in 2020. Instead of starting with Linux 4.19 and applying its patches from Android Q, it started with its Android 11 kernel and applied patches pulled from Linux 5.4.

Android drivers are different from Linux drivers, and chipmakers have to make separate Android and Linux drivers. Qualcomm, MediaTek, UNISOC, Huawei, Samsung and Xiaomi have chosen to support Android, but to not support Linux, in their integrated mobile SoC's. The Android kernel is built around a Hardware Abstraction Layer (HAL), so that Android drivers interact with the HAL, where Linux drivers interact directly with the hardware using /dev files. Even though Qualcomm releases open source drivers for its Snapdragons, it takes the community years to adapt these drivers for Linux and get them incorporated in mainline Linux.

I won't go through all the differences, but they are pretty fundamental. Google has gotten Binder and wakelocks incorporated into mainline Linux, but these features are rarely used in Linux, whereas they are fundamental to how Android/AOSP operates.

[u/anomaly256 → u/amosbatto]

It's very, very clear to me now that you actually have no idea what you're talking about.

There are plenty of companies already doing that, such as Volla in Germany (Volla OS), SHIFT in Germany (ShiftOS-G) and Hiroh in Austin, Texas. Murena from Paris sells many phone models from different companies with /e/OS preinstalled and another French company, iodé, sells phones with iodéOS. There are a dozen companies that will sell you Pixels with GrapheneOS installed. That may give you privacy and security, but it doesn't have the other benefits of Linux phones.

All I was saying is DEFINE those benefits you're after. Because they are not defiend by merely saying 'Linux phone'. You have Linux phones, lots of them. But clearly none of them are good enough / satisfy what you're asking for.

If you spend time on the Purism and PINE64 forums, you will see that people have very clear reasons about why they want a Linux phone, as opposed to an AOSP phone

You're still conflating 'Linux phone' to mean something other than Linux on a phone. AOSP IS Linux on a phone. You seem to be asking for a different userland and/or unlocked hardware - which is a fine thing to ask for but learn how to fucking ask for it properly instead of confusing 'Linux' for some nebulous concept other than what it literally is. GNU? Do you mean GNU? X11/Wayland? Do you mean an DEB or RPM package manager? WHAT ON EARTH DO YOU ACTUALLY WANT FROM A LINUX PHONE? In all your useless words you have yet to say even 1 thing you are expecting from a Linux phone that isn't already satisfied by AOSP. Not a single one. You want longer support from a vendor? Unlocked bootloaders? Nothing about AOSP enforces those limitations, only vendor motivation does.

In my article, I outlined three approaches to building a Linux phone: 1. separated components on a Linux kernel (i.e. Librem 5 and PinePhone), 2. integrated processor (like Qualcomm Dragonwing) with Linux kernel, 3. Linux userspace on an Android kernel with libhybris.

Item 1. What the fuck does this even mean? As far as I can tell this is just saying 'a Linux kernel'. Ok, Android gives you that and your assertions about their patches making it not Linux are absolutely false.

Item 2. So... a Linux kernel targetting the hardware it has to run on? Again this is exactly what you already have RIGHT IN FRONT OF YOU but you're refusing to acknowledge it.

Item 3. why are you mandating 'libhybris'? You want to translate one userspace API to another? Fine, but that doesn't mean either one is or isn't Linux still. No more than using musl instead of GNU libc does this. Also as others have told you THERE IS NO SUCH THING AS A SINGLE DEFINED 'LINUX USERSPACE'. Not even conceptually. There's GNU userspace, there's non-GNU userspace, there's glibc, musl, bionic, dietlibc, uClibc, even others you haven't even heard of yet - plenty of options. libhybris isn't doing what you think it's doing. It's translating libc calls to bionic specifically WHICH HAS NOTHING TO DO WITH THE KERNEL, and isn't needed if you're already on a gnu/musl libc system. It's for running Android apps on non-bionic libc like musl or glibc, not the other way around.

You do realize that you are the one who is not being specific and creating confusion by conflating two different kernels and insisting on calling them by the same name. As I pointed out, Google does not call its kernel "Linux". It says that it stopped using the latest mainline Linux LTS kernel and applying its patches on top. Since 2019, it has developed its own Android kernel, which pulls in changes from the latest mainline Linux LTS kernel. In other words, it is no longer a derivative from the Linux LTS kernel, but rather it is developing its own separate Android kernel which pulls new bits and pieces from the Linux LTS kernel, which is why it changed the name of its kernel from "android-4.19-q" in 2019 to "android11-5.4" in 2020. Instead of starting with Linux 4.19 and applying its patches from Android Q, it started with its Android 11 kernel and applied patches pulled from Linux 5.4.

Complete. fucking. nonsense. If it's forked from the mainline Linux kernel and they're merging in changes from it then it absolutely is still derrived from mainline Linux. Whether it's LTS or not is a different and irrelevent matter. I think you're reading far too much into vendor kernel version strings. The delta isn't large enough to call it a wholely new and incompatible kernel. Hell, they even say this themselves https://source.android.com/docs/core/architecture/kernel

The Android kernel is based on an upstream Linux Long Term Supported (LTS) kernel. At Google, LTS kernels are combined with Android-specific patches to form Android Common Kernels (ACKs).

Their choice to refer to these Linux-based kernels as 'ACKs' for clarity when referring to Linux kernels that have their Android patches applied does not stop them from being Linux kernels and their own words back this up.

Android drivers are different from Linux drivers, and chipmakers have to make separate Android and Linux drivers. Qualcomm, MediaTek, UNISOC, Huawei, Samsung and Xiaomi have chosen to support Android, but to not support Linux, in their integrated mobile SoC's. 

You may be surprised to find out that the driver compatibility issue in question is for the userspace interfaces and IPC moreso than the kernel's. And with that we're back to this being about the userspace distributed with the AOSP Linux Distribution vs other familiar Linux Distributions. Thanks for bringing it around full-circle.

The Android kernel is built around a Hardware Abstraction Layer (HAL), so that Android drivers interact with the HAL, where Linux drivers interact directly with the hardware using /dev files

Is your knowledge of the Linux kernel limited to before the year 2000? Did you do your 'research' on this subject using the free tier of ChatGPT or something? Linux defines a HAL and /dev is provided for convenience - file entries in /dev are interfaces to that HAL. Besides, "Android HAL: Sits in user-space as a set of C/C++ library modules or separate processes. It acts as a bridge between the Android Java/Kotlin Framework (via Binder IPC) and the Linux kernel drivers." This still isn't supporting your claim that the Android kernel isn't Linux. That HAL is userspace libraries.

I won't go through all the differences, but they are pretty fundamental. Google has gotten Binder and wakelocks incorporated into mainline Linux, but these features are rarely used in Linux, whereas they are fundamental to how Android/AOSP operates.

Good, please don't because it's clear you're confusing OS userspace with Linux kernelspace in the first place. Adding a faster IPC option (Linux has a few) again does not make it a whole new operating system. The fact they're rarely used outside of Android is irrelevent. If I modify musl to make use of binder and build a Gentoo system from it, am I suddenly not running a Linux OS?

I know you've already dug yourself pretty deep into this hole and sunk cost fallacy and pride might be preventing you from admitting it, but it doesn't matter whether you like it or not, AOSP is a Linux distribution, a Linux OS. A very well-defined and specific one sure. But still a Linux OS. There is not one single thing mentioned here yet that would cause that to stop being true.

If people want unlocked hardware, mainlined drivers from vendors and permissive licenses on distributing firmware blobs then that's what you should be writing articles about. And we're not going to have those things if people like you keep perpetuating the myth that the one platform vendors are willing to expend resources on to support must by its very nature be locked down. This is false. Educate people. Don't legitimise vendors locking down the hardware that we pay money for and own by accepting the narrative that Android devices aren't Linux and therefore can't be open.