I received several dozen comments to my previous article, "Will Linux phones become a viable alternative to the Android/iOS duopoly?" (https://news.ycombinator.com/item?id=50051530), asking why bother developing mobile Linux when we already have a mobile Linux operating system available with the Android Open Source Project (AOSP). They argued that there is no reason to develop another mobile Linux OS, when we already can use the most popular one available, and it gives us access to millions of apps.
In this blog article, I go through the reasons why the community would struggle to fork AOSP or even add changes to each new AOSP release from Google that empowers users and maintains their freedom like mobile Linux. Here is the central argument:
> Given how Maemo Leste and UBports have struggled to maintain the large codebases developed by Nokia and Canonical, respectively, it is not realistic to expect that the community can fork an enormous project like AOSP with 309 million lines of code. Even if the AOSP fork can be rebased every year on each new AOSP release by Google, it will still be a huge amount of work to keep refactoring the code each year so the AOSP fork respects and empowers the user like mobile Linux does. If Google ever stops releasing AOSP, there is virtually no way that the community will be able to replicate all the code changes that Google is making with each new version of Android, so the community fork will diverge over time from Google’s version. As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
Not only do I appreciate Purism's upstream-first policy when developing its software, I also appreciate the fact that its developers take the time to answer people's questions. Purism charges high prices, but I think the company is worth supporting.
Purism's public reputation was blackened by its decision to stop repaying the refunds to people who canceled their Librem 5 pre-orders after Feb. 2020. I think that decision allowed the company to finish developing the Librem 5 phone and start shipping it in Nov. 2020, but you will find a lot of negative comments online about the company (see Reddit's r/Purism). I often point out the positive aspects about the company, because the company gave a lot to the community by developing libadwaita and Phosh, but some people don't see it that way.
> The problem is that Android was designed as a vehicle to collect the personal information of users to feed that data to Google’s servers for its targeted advertising.
It is true that Google's services (their web services and apps) use data collection as a revenue stream. Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model. This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.
> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.
Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.
Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.
These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.
> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.
Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all. The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
> Amount of malware and Potentially Unwanted Applications (PUAs) on different operating systems [TABLE]
Kind of irrelevant to look at absolute numbers. Malware and PUAs are hard to define as concepts and it's also difficult to measure or determine whether something falls under that definition. And counting them is also a form of non-exhaustive enumeration.
> The important point is that Phosh is already a very solid interface and the tweaks that it needs are minor compared to the significant dev work that AOSP will require to make it an operating system that respects and empowers users. Even in the case of Plasma Mobile, the dev work that it requires is far less than AOSP would require. The work to improve the Phosh and Plasma Mobile interfaces is a one-time cost, whereas the code churn in AOSP will make it a constant struggle to keep reapplying changes with each new version that gets released by Google.
AOSP respects and empowers users much more than traditional Linux due to the proper security and privacy model, as I mentioned before. Trying to add something similar to Linux would be a very resource-heavy task and will break compatibility with a lot of apps because those are written with the expectation of having wide access to your system. So, you would also have to rewrite those apps, which would make it even more resource-heavy.
> As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
If this hypothetical scenario that you've been painting in your blog post would happen then it's likely that the large FOSS ecosystem of Android apps will target the community AOSP fork instead of the hypothetical closed source Google Android. There are lot of FOSS Android apps, which can compete with the traditional Linux app ecosystem and even outcompete it for various app categories.
> Linux users are less likely to install rogue apps, because they can’t just find any random Linux software package on the internet and install it, like they can with random APK files found on the internet.
Many people use the AUR. An app being available in a package manager or on FlatHub doesn't mean it's well written or well maintained. And, nobody forces you to grab APKs from random sources, you can stick to reputable app stores or to the official websites and repositories of developers you decide to trust.
> However, Linux phones will need to be able to install Android apps if they are going to appeal to the mass market.
This seems to undermine most of the point you are trying to make.
> Even when those Android apps are run inside an LXC container, mobile Linux still needs to be prepared for all the malware and spyware that comes with running Android apps.
Doesn't make sense to want to use a more secure and private OS as a guest on a less private and secure host. It should be the reverse. LXC containers also aren't proper isolation like a VM.
You can perfectly run malware and spyware on desktop Linux, nothing is preventing you technically from doing so. On Android, contrary to desktop Linux, the system will prevent those apps from having invasive access to your system and user data, because of the permission model. On Linux, malicious software has more invasive access and can more easily escalate to even higher levels of access.
> However, adding good userspace security to mobile Linux won’t be nearly as much work as adding user empowerment features to AOSP. It will be difficult to convince long-time Linux users to accept application sandboxing with separate users and separate file encryption for each app, and it will probably require some experimentation to get the right balance between security and freedom. Nonetheless, it is wrongheaded to treat the dev work for better security in mobile Linux as an insurmountable task.
It's not wrongheaded. It will break a lot of software. It will ask a lot of time. Time which is reinventing the wheel because Android exists. And it will get a lot of counter from a desktop Linux culture which seems to care little about security and mostly cares about being able to modify as much things as possible to the extent of even being able to break stuff, because 'freedom'.
> It is important to recognize, however, that many Linux phones either come with AOSP preinstalled or have it installed by their users in o...
> The problem is that Android was designed as a vehicle to collect the personal information of users to feed that data to Google’s servers for its targeted advertising.
It is true that Google's services (their web services and apps) use data collection as a revenue stream. Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model. This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.
> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.
Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.
Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.
These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.
> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.
Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all. The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
Before we start this debate, let me state from the outset that I have been installing AOSP derivatives on my own phones since 2015, and I don't want to disparage all the hard work being done by the volunteers at LineageOS, GrapheneOS, and the other custom ROMs.
However, if the long-term goal is digital freedom and user empowerment, dependence on Google puts us in a very precarious position, and I suspect that Google and the phone brands will keep turning the screws and making it harder and harder for the AOSP-derivatives to keep operating, because the business model of the mobile industry is changing from planned obsolescence to surveillance capitalism and the monetizing of people's personal data. The tech giants are in a fierce race to collect as much of our personal data as possible in order to train their LLMs. Although the current AI bubble will pop, just like the Internet bubble popped in 2001-2, that didn't stop the Internet from becoming the predominant paradigm for the tech industry, and AI will probably follow a similar trajectory, so I don't think the financial incentives to collect our personal data for targeted advertising and AI training will stop.
As I explained in my previous article on Linux phones, the smartphone brands that permit unlocking of the bootloader have dropped from 42.5% to 7% of the market in recent years. The brands which allow their bootloaders to be unlocked (without major restrictions like Xiaomi) only sold about 87 million phones in 2025, including Lenovo/Motorola (60M), Google (12M), OnePlus (11.6M), Nothing (2M), GigaSet (>1M), Sony (400k), Fairphone (145k), SHIFT (10k), Teracube, Volla and Brax. The number of new phones sold in 2025 that have official LineageOS ports and aren't locked by carriers is probably around 20 million phones or 2% of the global smartphone market, and that number will probably drop to 10 million per year as Motorola keeps switching more of its phones away from Snapdragon processors, OnePlus is pulling out of Europe and North America and Nothing is cutting staff and will probably pull out of many markets. In other words, our ability to install custom ROMs will keep being restricted. For people living in Iran and most of Africa, there is not a single new phone on the market that has an official LineageOS port. In some African countries (Kenya, South Africa, Nigeria, Ghana and Eygpt), most of Latin America (except Mexico) and most of Asia (except Japan, Taiwan, Singapore, India and Malaysia), they only have one new phone on the market with an official LineageOS port, which is the Motorola Moto G15 that was released in December 2024.
We are becoming increasingly dependent on Google for both the software and hardware to run AOSP phones. For most of the world, Motorola is the only option to install an AOSP derivative, which means waiting 3 to 14 days just to unlock the bootloader, or buying a used Xiaomi and dealing with Xiaomi's insane policies to get an unlock code.
We need to support the Linux phone companies, because we have no idea how much longer Google will continue to release AOSP, and we are totally screwed if Motorola or Google change their bootloader unlock policies. None of your arguments convince me that the community can maintain an AOSP fork with 309 million lines of code, whereas we know that the Phosh and Plasma Mobile interfaces and the existing mobile Linux distros like SailfishOS, Ubuntu Touch, Nura, Mobian, DanctNIX, Droidian, etc. can be maintained by the community.
OK, let me try to address some of your specific points in subsequent comments below.
> Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model.
The problem with Android's "fine-grained run-time permission model" is that most users learn very quickly that if they don't grant Android apps all the permissions that they ask for, they won't have the app's full functionality. I have played this game many times with Android apps, where I only grant them the permissions that I think are strictly necessary. However, after I start using the app, I constantly discover that I keep needing to grant them more and more permissions. In the end, it becomes such a hassle to keep being asked for permissions, that I almost always end up giving every app all the permissions that it asks for.
It is far better for most users to have their apps preconfigured to only grant the permissions that they need by distros and companies who care about protecting users and keeping their data private. As a user, I don't want to have to scrutinize every app that I install and check whether the business model of the app creator is based on surveillance capitalism or malware. Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me. Yes, I know that Firefox is paid to set Google as the default search engine and Canonical tried a few schemes in the past like its Amazon Shopping Lens in 2012-16, but those are anomalies in the Linux world, whereas they are the norm in the Android world.
> Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all.
Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla, and I know that the F-Droid community did a good job of reviewing the code that I submitted to them. I have a personal beef with how Daniel Micay treats other FOSS projects, but GrapheneOS does a good job of protecting its users. However, I know from personal experience that I always end up installing apps based on surveillance capitalism on my AOSP phones, because I always end up needing some Android app. In 27 years of using Linux, I haven't installed any malware or spyware that I know of (beyond Firefox's Google search), and that is the common experience of most Linux users. (See below for further argument.)
> This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc).
If you are arguing that mobile Linux needs to improve its userspace security model, then I agree. I'm not saying that Flatpak is perfect. My argument is that it is much easier to improve mobile Linux's security model than to fork AOSP or even just replace the user anti-features in each new release of AOSP.
> The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
True, there have been instances, such as OpenSSH's CVE-2026-35414, where they didn't catch the problem for 15 years, and you mentioned the xz backdoor, where someone (probably the Israeli government) was deliberately introducing security holes. In general, the Linux distros have been lulled into a sense of complacency since they haven't had major security issues like Windows and Android have had in the past. I think the real issue is the fact that the major Linux companies (IBM/Red Hat, SUSE, Canonical and Google) are mainly focused on servers, where userspace security isn't an important factor. If your argument is that mobile Linu...
> I have played this game many times with Android apps
I haven't had this issue myself and fortunately GrapheneOS has its scopes features and more are coming, so it's still possible to use a more private and secure OS without having to cave in like you're saying. For example, WhatsApp might think it needs access to contacts and GrapheneOS users can let the app think it has access to everything while it really doesn't.
Also, what makes you think that apps that demand too much will never exist on other OSes? You seem to be blaming AOSP for app developers' behavior.
> Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me.
Again, it doesn't make sense to judge entire OSes based on your experience with apps. The argument doesn't make any sense. You can't say that an entire OS is private and secure because the apps you use aren't trying to invade your privacy or exploit security holes.
> Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla
Murena is plagued with issues, their OS rolls back privacy, is far behind on updates, they were sending data to OpenAI without informing users first, their cloud services were down for months and at one point mixed up user IDs and users' data was being synced to the wrong devices. They're hardly a good example.
iodéOS and Volla have the same problems with their OS as /e/OS.
> I have a personal beef
Members of the GrapheneOS project (myself included) call these projects out because they're misleading their users. We believe that people have the right to privacy and it's awful to see people being duped.
It's also ridiculous that we are attacking anyone. It's ironic that you name Murena and iodéOS in the same paragraph and accuse _us_ of attacking other projects.
Gael Duval has attacked GrapheneOS many times. He has called us toxic, violent, our supporters idiots and zealots. He even said that devices with strong privacy and security are for pedophiles.
iodéOS is or was at least partnered with someone who has also attacked GrapheneOS regularly, Robert Braxman. He has also insulted members of our project. He has also told clear lies about GrapheneOS on his channel in order to promote his less private and secure devices. He is a scam artist with a YouTube following.
(1/3) Let's estabilish some axioms. Firstly, user experience in non-AOSP and non-iOS mobile OS' is rocky, to be polite, and whoever uses them usually admits such fact wholeheartedly. Secondly, much like Linux isn't an OS, Android isn't either (AOSP is); the post didn't consider AOSP-based OS' as even belonging to the same conceptual box of "there are many of these" (let alone go beyond this), but the same concept is considered a great thing about non-AOSP mobile OS'. Lastly, the post is very idealistic.
The proposition of dreaming about distinct non-AOSP OS' undergoing immense changes in order to catch up to what constitutes a good user experience and actual user empowerment make the entire thing a non-starter since it requires being very idealistic to argue in favor of, specially when you consider that idealistically it is more worthy to further advance AOSP-based projects, whether in terms of OS development, reverse engineering, or taking part in the development of more user-respecting and useful apps.
Non-AOSP Linux OS' do not empower the user in terms of privacy and security because users are not able to restrict resource access from applications at will and with ease, whereas AOSP employs a runtime permission model where the user is asked what access they want to grant to an app, only when it means to access it. This includes ephemeral (time- and focus-based) access where it makes sense (eg. microphone and camera, and location, respectively), as well as granular file and media access for apps using modern APIs, which they are forced to if they want to target higher API levels (newer Android versions) which deprecate older APIs in isolation. API level 34 (Android 14) finalized the introduction of granular file and media access. New AOSP versions progressively employ more privacy and security protections considered in the design of the platform API (nonwithstanding the design of the rest of the OS), and AOSP has solid backwards compatibility because SDK targets are fixed and don't change between releases, to a point apps that target lower API levels can use older AOSP APIs that exist in such API level, which have less solid privacy protections... although even then, the permission model is sovereign.
As such, any app store worth its salt will delist apps that fail to keep up. Today, Google Play Store only lets users download apps targeting API level 34 (Android 14) or lower if a device runs Android 14 or lower. New apps and app updates must target API level 36 (Android 16). Apps targeting even the latest API level are still compatible with many old Android versions, with how far compatibility goes being a developer choice. The aforementioned granular media access APIs remained stable since Android 13, file access APIs for longer, and needed little adaptation going forward since their introduction, yet users got progressively more control over apps in their device.
I can't be bothered to refute the same old arguments the Android fanbois have made in this thread (especially with the HN character limits) so I'll just make one statement - make a hard fork of AOSP, reverse all the unpopular user restrictions Google introduced in recent years, allow a way to easily install and switch DMs/WMs/DEs like you can on desktop Linux, and finally patch it in a timely and regular fashion without directly importing any code from AOSP or other AOSP derivatives. Do that for at least an year, and I'll listen to you.
Otherwise, you can't convince me that Android is equivalent to or better than desktop Linux, in terms of freedom. The #1 most important thing that I want from an OS installed on my personal device, is freedom. It's my device, I own it, I should be allowed to do whatever then hell I want to with it, I should be able to customise it however I want, without some megacorporation or megacorporation-sympathisers dictating what I can/can't do with my device.
11 comments
[ 0.25 ms ] story [ 27.9 ms ] threadIn this blog article, I go through the reasons why the community would struggle to fork AOSP or even add changes to each new AOSP release from Google that empowers users and maintains their freedom like mobile Linux. Here is the central argument:
> Given how Maemo Leste and UBports have struggled to maintain the large codebases developed by Nokia and Canonical, respectively, it is not realistic to expect that the community can fork an enormous project like AOSP with 309 million lines of code. Even if the AOSP fork can be rebased every year on each new AOSP release by Google, it will still be a huge amount of work to keep refactoring the code each year so the AOSP fork respects and empowers the user like mobile Linux does. If Google ever stops releasing AOSP, there is virtually no way that the community will be able to replicate all the code changes that Google is making with each new version of Android, so the community fork will diverge over time from Google’s version. As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
Purism's public reputation was blackened by its decision to stop repaying the refunds to people who canceled their Librem 5 pre-orders after Feb. 2020. I think that decision allowed the company to finish developing the Librem 5 phone and start shipping it in Nov. 2020, but you will find a lot of negative comments online about the company (see Reddit's r/Purism). I often point out the positive aspects about the company, because the company gave a lot to the community by developing libadwaita and Phosh, but some people don't see it that way.
It is true that Google's services (their web services and apps) use data collection as a revenue stream. Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model. This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.
> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.
Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.
Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.
These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.
> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.
Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all. The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
> Amount of malware and Potentially Unwanted Applications (PUAs) on different operating systems [TABLE]
Kind of irrelevant to look at absolute numbers. Malware and PUAs are hard to define as concepts and it's also difficult to measure or determine whether something falls under that definition. And counting them is also a form of non-exhaustive enumeration.
> ...
AOSP respects and empowers users much more than traditional Linux due to the proper security and privacy model, as I mentioned before. Trying to add something similar to Linux would be a very resource-heavy task and will break compatibility with a lot of apps because those are written with the expectation of having wide access to your system. So, you would also have to rewrite those apps, which would make it even more resource-heavy.
> As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
If this hypothetical scenario that you've been painting in your blog post would happen then it's likely that the large FOSS ecosystem of Android apps will target the community AOSP fork instead of the hypothetical closed source Google Android. There are lot of FOSS Android apps, which can compete with the traditional Linux app ecosystem and even outcompete it for various app categories.
> Linux users are less likely to install rogue apps, because they can’t just find any random Linux software package on the internet and install it, like they can with random APK files found on the internet.
Many people use the AUR. An app being available in a package manager or on FlatHub doesn't mean it's well written or well maintained. And, nobody forces you to grab APKs from random sources, you can stick to reputable app stores or to the official websites and repositories of developers you decide to trust.
> However, Linux phones will need to be able to install Android apps if they are going to appeal to the mass market.
This seems to undermine most of the point you are trying to make.
> Even when those Android apps are run inside an LXC container, mobile Linux still needs to be prepared for all the malware and spyware that comes with running Android apps.
Doesn't make sense to want to use a more secure and private OS as a guest on a less private and secure host. It should be the reverse. LXC containers also aren't proper isolation like a VM.
You can perfectly run malware and spyware on desktop Linux, nothing is preventing you technically from doing so. On Android, contrary to desktop Linux, the system will prevent those apps from having invasive access to your system and user data, because of the permission model. On Linux, malicious software has more invasive access and can more easily escalate to even higher levels of access.
> However, adding good userspace security to mobile Linux won’t be nearly as much work as adding user empowerment features to AOSP. It will be difficult to convince long-time Linux users to accept application sandboxing with separate users and separate file encryption for each app, and it will probably require some experimentation to get the right balance between security and freedom. Nonetheless, it is wrongheaded to treat the dev work for better security in mobile Linux as an insurmountable task.
It's not wrongheaded. It will break a lot of software. It will ask a lot of time. Time which is reinventing the wheel because Android exists. And it will get a lot of counter from a desktop Linux culture which seems to care little about security and mostly cares about being able to modify as much things as possible to the extent of even being able to break stuff, because 'freedom'.
> It is important to recognize, however, that many Linux phones either come with AOSP preinstalled or have it installed by their users in o...
> The problem is that Android was designed as a vehicle to collect the personal information of users to feed that data to Google’s servers for its targeted advertising. It is true that Google's services (their web services and apps) use data collection as a revenue stream. Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model. This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc). You can use AOSP-based OSes without storing your personal data into Google apps and services if you don't want to hand it to those, you can instead use third-party alternatives with better privacy.
> AOSP is designed with these onerous security restrictions because so much of the software installed in Android comes from untrustworthy sources. Unlike the typical Linux distro, where the vast majority of the code is free/open source, the code of the vast majority of Android apps can’t be publicly reviewed for malicious intent.
Proper app stores like Google Play Store and Accrescent do verification of the applications you download to verify that it's an untampered app made by the actual developer. After first install, the signature gets pinned as well. This is much better than some ways people obtain software on traditional Linux distributions. These app stores can also offer FOSS applications. FOSS applications are for example available on Google Play Store and Accrescent. There is also a large ecosystem available on GitHub, for which you can also verify the signature using dedicated apps and which are also protected by signature pinning after first install.
Of course these measures don't protect you against a malicious developer, no technical measure can. If you don't trust the developers, you simply shouldn't use their software for actual personal use. Code being free and open source doesn't change that. A skilled developer can perfectly hide malicious code in the source. Code review of open source code is imperfect and often doesn't happen systematically enough to catch such things. Note the xz backdoor. If review would happen systematically, it isn't exclusive to OSS. You can also research the code of closed sourced software, such software isn't a black box. It can be analysed, decompiled, etc. Note how the xz backdoor was discovered.
These are also more security problems than simply malicious code. A developer can also make mistakes or not do due diligence. This can also pose security risks. Note that Android development practices much more incentivize good development and that Android apps heavily use memory safe code. This is contrary to traditional Linux apps.
> In a community-based Linux distro, it typically takes several years to become a maintainer of packages in the system under the guidance of a mentor who checks packages before they get uploaded to the system. The public reputations of Linux package maintainers (and their mentors who sponsored them) are staked on keeping malicious code out of the system.
Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all. The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
However, if the long-term goal is digital freedom and user empowerment, dependence on Google puts us in a very precarious position, and I suspect that Google and the phone brands will keep turning the screws and making it harder and harder for the AOSP-derivatives to keep operating, because the business model of the mobile industry is changing from planned obsolescence to surveillance capitalism and the monetizing of people's personal data. The tech giants are in a fierce race to collect as much of our personal data as possible in order to train their LLMs. Although the current AI bubble will pop, just like the Internet bubble popped in 2001-2, that didn't stop the Internet from becoming the predominant paradigm for the tech industry, and AI will probably follow a similar trajectory, so I don't think the financial incentives to collect our personal data for targeted advertising and AI training will stop.
As I explained in my previous article on Linux phones, the smartphone brands that permit unlocking of the bootloader have dropped from 42.5% to 7% of the market in recent years. The brands which allow their bootloaders to be unlocked (without major restrictions like Xiaomi) only sold about 87 million phones in 2025, including Lenovo/Motorola (60M), Google (12M), OnePlus (11.6M), Nothing (2M), GigaSet (>1M), Sony (400k), Fairphone (145k), SHIFT (10k), Teracube, Volla and Brax. The number of new phones sold in 2025 that have official LineageOS ports and aren't locked by carriers is probably around 20 million phones or 2% of the global smartphone market, and that number will probably drop to 10 million per year as Motorola keeps switching more of its phones away from Snapdragon processors, OnePlus is pulling out of Europe and North America and Nothing is cutting staff and will probably pull out of many markets. In other words, our ability to install custom ROMs will keep being restricted. For people living in Iran and most of Africa, there is not a single new phone on the market that has an official LineageOS port. In some African countries (Kenya, South Africa, Nigeria, Ghana and Eygpt), most of Latin America (except Mexico) and most of Asia (except Japan, Taiwan, Singapore, India and Malaysia), they only have one new phone on the market with an official LineageOS port, which is the Motorola Moto G15 that was released in December 2024.
We are becoming increasingly dependent on Google for both the software and hardware to run AOSP phones. For most of the world, Motorola is the only option to install an AOSP derivative, which means waiting 3 to 14 days just to unlock the bootloader, or buying a used Xiaomi and dealing with Xiaomi's insane policies to get an unlock code.
We need to support the Linux phone companies, because we have no idea how much longer Google will continue to release AOSP, and we are totally screwed if Motorola or Google change their bootloader unlock policies. None of your arguments convince me that the community can maintain an AOSP fork with 309 million lines of code, whereas we know that the Phosh and Plasma Mobile interfaces and the existing mobile Linux distros like SailfishOS, Ubuntu Touch, Nura, Mobian, DanctNIX, Droidian, etc. can be maintained by the community.
OK, let me try to address some of your specific points in subsequent comments below.
The problem with Android's "fine-grained run-time permission model" is that most users learn very quickly that if they don't grant Android apps all the permissions that they ask for, they won't have the app's full functionality. I have played this game many times with Android apps, where I only grant them the permissions that I think are strictly necessary. However, after I start using the app, I constantly discover that I keep needing to grant them more and more permissions. In the end, it becomes such a hassle to keep being asked for permissions, that I almost always end up giving every app all the permissions that it asks for.
It is far better for most users to have their apps preconfigured to only grant the permissions that they need by distros and companies who care about protecting users and keeping their data private. As a user, I don't want to have to scrutinize every app that I install and check whether the business model of the app creator is based on surveillance capitalism or malware. Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me. Yes, I know that Firefox is paid to set Google as the default search engine and Canonical tried a few schemes in the past like its Amazon Shopping Lens in 2012-16, but those are anomalies in the Linux world, whereas they are the norm in the Android world.
> Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all.
Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla, and I know that the F-Droid community did a good job of reviewing the code that I submitted to them. I have a personal beef with how Daniel Micay treats other FOSS projects, but GrapheneOS does a good job of protecting its users. However, I know from personal experience that I always end up installing apps based on surveillance capitalism on my AOSP phones, because I always end up needing some Android app. In 27 years of using Linux, I haven't installed any malware or spyware that I know of (beyond Firefox's Google search), and that is the common experience of most Linux users. (See below for further argument.)
> This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc).
If you are arguing that mobile Linux needs to improve its userspace security model, then I agree. I'm not saying that Flatpak is perfect. My argument is that it is much easier to improve mobile Linux's security model than to fork AOSP or even just replace the user anti-features in each new release of AOSP.
> The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.
True, there have been instances, such as OpenSSH's CVE-2026-35414, where they didn't catch the problem for 15 years, and you mentioned the xz backdoor, where someone (probably the Israeli government) was deliberately introducing security holes. In general, the Linux distros have been lulled into a sense of complacency since they haven't had major security issues like Windows and Android have had in the past. I think the real issue is the fact that the major Linux companies (IBM/Red Hat, SUSE, Canonical and Google) are mainly focused on servers, where userspace security isn't an important factor. If your argument is that mobile Linu...
I haven't had this issue myself and fortunately GrapheneOS has its scopes features and more are coming, so it's still possible to use a more private and secure OS without having to cave in like you're saying. For example, WhatsApp might think it needs access to contacts and GrapheneOS users can let the app think it has access to everything while it really doesn't.
Also, what makes you think that apps that demand too much will never exist on other OSes? You seem to be blaming AOSP for app developers' behavior.
> Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me.
Again, it doesn't make sense to judge entire OSes based on your experience with apps. The argument doesn't make any sense. You can't say that an entire OS is private and secure because the apps you use aren't trying to invade your privacy or exploit security holes.
> Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla
Murena is plagued with issues, their OS rolls back privacy, is far behind on updates, they were sending data to OpenAI without informing users first, their cloud services were down for months and at one point mixed up user IDs and users' data was being synced to the wrong devices. They're hardly a good example.
iodéOS and Volla have the same problems with their OS as /e/OS.
> I have a personal beef
Members of the GrapheneOS project (myself included) call these projects out because they're misleading their users. We believe that people have the right to privacy and it's awful to see people being duped.
It's also ridiculous that we are attacking anyone. It's ironic that you name Murena and iodéOS in the same paragraph and accuse _us_ of attacking other projects.
Gael Duval has attacked GrapheneOS many times. He has called us toxic, violent, our supporters idiots and zealots. He even said that devices with strong privacy and security are for pedophiles.
iodéOS is or was at least partnered with someone who has also attacked GrapheneOS regularly, Robert Braxman. He has also insulted members of our project. He has also told clear lies about GrapheneOS on his channel in order to promote his less private and secure devices. He is a scam artist with a YouTube following.
The proposition of dreaming about distinct non-AOSP OS' undergoing immense changes in order to catch up to what constitutes a good user experience and actual user empowerment make the entire thing a non-starter since it requires being very idealistic to argue in favor of, specially when you consider that idealistically it is more worthy to further advance AOSP-based projects, whether in terms of OS development, reverse engineering, or taking part in the development of more user-respecting and useful apps.
Non-AOSP Linux OS' do not empower the user in terms of privacy and security because users are not able to restrict resource access from applications at will and with ease, whereas AOSP employs a runtime permission model where the user is asked what access they want to grant to an app, only when it means to access it. This includes ephemeral (time- and focus-based) access where it makes sense (eg. microphone and camera, and location, respectively), as well as granular file and media access for apps using modern APIs, which they are forced to if they want to target higher API levels (newer Android versions) which deprecate older APIs in isolation. API level 34 (Android 14) finalized the introduction of granular file and media access. New AOSP versions progressively employ more privacy and security protections considered in the design of the platform API (nonwithstanding the design of the rest of the OS), and AOSP has solid backwards compatibility because SDK targets are fixed and don't change between releases, to a point apps that target lower API levels can use older AOSP APIs that exist in such API level, which have less solid privacy protections... although even then, the permission model is sovereign.
As such, any app store worth its salt will delist apps that fail to keep up. Today, Google Play Store only lets users download apps targeting API level 34 (Android 14) or lower if a device runs Android 14 or lower. New apps and app updates must target API level 36 (Android 16). Apps targeting even the latest API level are still compatible with many old Android versions, with how far compatibility goes being a developer choice. The aforementioned granular media access APIs remained stable since Android 13, file access APIs for longer, and needed little adaptation going forward since their introduction, yet users got progressively more control over apps in their device.
Otherwise, you can't convince me that Android is equivalent to or better than desktop Linux, in terms of freedom. The #1 most important thing that I want from an OS installed on my personal device, is freedom. It's my device, I own it, I should be allowed to do whatever then hell I want to with it, I should be able to customise it however I want, without some megacorporation or megacorporation-sympathisers dictating what I can/can't do with my device.