The Advantages of Mobile Linux over AOSP (LineageOS, CrDroid, GrapheneOS, etc.)
amosbbatto.wordpress.com
amosbbatto.wordpress.com
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.
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.
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 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.
There are none of the few implied protections for apps that aren't Flatpak. Who exactly is empowered by not restricting even common apps' reach over your every thing on your computer? Power user use cases are best considered with careful design choices and are not a good excuse to let everything have access to everything by default, or have an insufficient difference be decided by packaging formats like Flatpak, specially when so many developers outright reject it or misuse it and don't perform basic Flathub developer verification (which isn't even developer package signing, just proof of web domain ownership, making more unfathomable the fact so many choose to skip it).
FOSS doesn't mean free of malice or supply chain compromise risk, so acting like programs from any source are worthy of trust just because "of course" doesn't make sense. That is acting like security only matters when you think you aren't immune, for arbitrary reasons. It is simply sensible and effective to not trust programs and isolate them according to principle of least privilege, which handsomely agrees with the fabled UNIX philosophy. Android doesn't sandbox apps because it distrusts them from a "moral judgement" standpoint, contrasting with what the post, in a way, implies. An AOSP OS' primary app store is its trusted app source in the sense it has a little less friction to use than other app sources, but all apps are subject to the sandbox either way, including system apps. There are FOSS apps distributed in various app sources, including Play Store.
[0] https://blog.sebastianwick.net/posts/flatpak-happenings/
Lastly, a little pet peeve I have is with trying to push forward an idea of what is "commonly accepted" as the definition of "Linux" that completely ignores embedded systems, for a start. If you know, you know, which should be enough said as a response to an undefined common sense invocation. Linux is not GRUB, systemd, glibc, GNU coreutils, freedesktop.org standards and GNOME, nor is it defined by other software being drop-in replacements to those that have been mentioned (in terms or API compatibility or, for GNOME, in terms of being an arbitrary userland program choice). Linux is a kernel which AOSP uses with not really more divergence from upstream than an embedded Linux system that is still considered a Linux system exactly because Linux is not a definition of one OS, despite a hypothetical embedded system also potentially having a vastly different userland to traditional desktop and server Linux OS', maybe programs built using different SDKs than GTK and QT and SDL, a slimmed down kernel to purpose which, similarly to Android, is just built differently rather than significant new code. Every platform, whether mobile, embedded (as per this arbitrary-ish distinction of mine), desktop or server, will feature different drivers, firmware distributions or hardware tooling too, although desktop and server distros typically package and ship everything because why not, I guess.
I would make this comment thread longer and more comprehensive, had another user not done an analysis the size of my ambition which I largely agree with. [1]
[1] https://news.ycombinator.com/item?id=50268748
Edit: I failed to note that AOSP actually runs fine on mainline kernels, and even desktop and server Linux systems use a distro-vendored kernel build, with configuration at the distribution maintainers' discretion, which is only one degree of separation removed from what I indeed talked about.
> 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.
> Because most applications in Linux are installed from free/open source repositories, there are fewer opportunities to distribute applications that do things that users don’t want such as collecting and monetizing their personal data.
Software installed via traditional Linux package managers is unsandboxed, so it's a beautiful opportunity to collect personal data. Software distributed via Flatpak often requests a bunch of Flatpak permissions and as I said above Flatpak isn't a proper sandbox due to it not being fine-grained, not being properly run-time based and having numerous sandbox escape possibilities. So, also a good opportunity to take personal data. On Android, regardless of distribution means, apps are forced into the app sandbox and subject to a proper fine-grained run-time permission model.
> AOSP is not just designed to protect against malware, which abounds in the Android ecosystem; it is also designed to protect the system against the users themselves. AOSP makes users jump through all sorts of hoops in order to modify the system, because Google and the phone makers don’t want ordinary users modifying the system and customizing the environment to fit their needs. AOSP was purposely designed to restrict the freedom of ordinary users, so they won’t change what Google and the phone makers have preinstalled on their phones.
Exposing this to the user is also adding it as attack surface that an exploit can use to escalate and wreak havoc. Making the system hard to modify is a good way to ensure the integrity of the operating system and apply security features like Verified Boot.
> Then the display name has to be edited in the app’s AndroidManifest.xml file (or its linked string resources). The files have to be recompiled into a new APK package, and then the new APK file has to be signed with the user’s cryptography key. Then, the existing app has to be uninstalled, which means that the user will lose any data stored in the app’s files. Then, the new app can be installed in its place with the new name.
The existing app wouldn't have to be uninstalled if you also changed the app ID, as you are supposed to do. You shouldn't use an app ID used by another developer.
> In contrast, changing the name of an app in Linux usually just involves editing the app’s launcher or creating a link to the launcher with a different file name.
As you admit yourself this is more of a 'launcher' / DE thing than an app thing. So, third-party launchers or launchers of custom AOSP-based OSes could offer custom display names as a feature, just like some offer custom icons. Nothing inherent to AOSP prevents this. It's a much better idea to add this to a custom AOSP fork than to try to make traditional desktop Linux on phones happen.
> Mobile Linux distros, such as Sailfish OS, Ubuntu Touch, Nura, Mobian, DanctNIX, Droidian, Maemo Leste, Nemo Mobile, etc., are designed to empower the user to control the tech, rather than the tech being used as a means to control the user.
How do they let the user control the tech if they don't offer users a proper fine-grained run-time permission model to decide what they hand out to apps?
> the user should be empowered to modify the app’s launcher to modify how the app is executed, like in mobile Linux. If the user wants to add an environment variable to the launcher or execute an app with an option, it should not be necessary for the user to root the device and then execute complicated commands in the terminal [...]
If it makes sense to run an app in various ways, the app developers can add such functionality to their app and the app settings.
> It won’t be an easy task, because each time Google releases a new version of AOSP, these volunteers will have to rip out the anti-user features in the latest version and replace that code with user-empowerment features. Because Google makes substantial changes to Android every year, the user-empowerment code will likely need to be refactored every year to work in each new AOSP release.
Would be nice if you would be able to give examples of those anti-user features and examples of desired user-empowerment features. New Android versions and SDK levels often bring security and privacy improvements. The permission model has evolved a lot over time and has only evolved to give the user more control over their applications.
> Google is actively rewriting its Android code in Rust to eliminate memory safety vulnerabilities and speed up its software development.
Sounds amazing. What is the issue with this? Do they need to go slow on making the system more secure in order to make it easier for external contributors? Do you think that it would be a net-positive to deliberately slow down taking up Rust?
> 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 order to run Android apps. Almost every mobile Linux distro provides instructions and packages to install Waydroid and microG. Jolla’s license for Sailfish OS includes its proprietary AppSupport. FuriLabs’ FLX1/s/s+ includes Andromeda, which is its fork of Waydroid. All of these solutions run AOSP inside an LXC container. In addition, Valve just open sourced Lepton, which runs Android games as a non-root user in an AOSP container, but it doesn’t include Google Play Services or microG.
Those Android subsystems are almost always heavily outdated and have their security degraded. To give two examples: Waydroid doesn't use SELinux so doesn't have proper application sandboxing anymore and Sailfish OS is at Android 13, while we are currently on Android 17.
> Many of Google’s proprietary Play Services have been replicated by the free/open source microG, which uses signature spoofing to make Android apps believe that Google Play Services are installed. Nonetheless, microG doesn’t always work correctly in some situations, such as Google Maps’ geofencing, in-app billing, AR, SafetyNet/Play Integrity attestation, reCAPTCHA, PackageInfo.signingInfo, etc. Some apps fail security checks in Waydroid, because it appears to be a rooted Android device.
A solution like sandboxed Google Play used by GrapheneOS doesn't have most of the issues MicroG has. It's unaltered Google Play forced into the regular app sandbox. The only thing that really doesn't work with it are apps enforcing strong Play Integrity, which is an anti-trust issue that hopefully will be resolved in the future by regulators.
> Presumably Jolla’s AppSupport has been receiving AOSP upgrades, but Waydroid needs to be better supported in the future if Linux phones are going to rely on it to run Android apps.
Their official site says they reached Android 13, we are currently on Android 17.
> Instead of wasting resources on trying to fork AOSP, we should instead be focusing on how to better support Waydroid and microG for people who need to run Android apps.
Makes little sense to focus resources on the options to run Android apps insecurely. Better would be to donate resources or contributions to GrapheneOS and the GMSCompat project of GrapheneOS which enables running Google Play into the regular app sandbox.
> People often argue that using AOSP will provide access to more software, but that is not necessarily true if the goal is to only use free/open source software (FOSS). Google deliberately obscures the licensing of an app’s code from users by labeling both freeware and FOSS as “free” in its Play Store. There may be more total FOSS among those two million apps in the Play Store than in the Linux repositories, but selecting out the FOSS apps, vetting their code and organizing those apps into a separate repository will not be an easy task.
Vetting apps is an ongoing and imperfect task on desktop Linux as well. The Accrescent app store which is currently in development for Android will in the future offer a filter option to filter actual FOSS apps from proprietary apps. Labelling apps properly really isn't impossible.
> In contrast, Google is constantly changing the standards for its apps and forcing app creators to constantly update their code to keep their apps in the Play Store.
This is also due to the introduction of new privacy and security features that are part of newer SDK levels. That's part of the user empowerment you wanted to see. If Linux would add user-friendly security and privacy features that are mandatory, a lot of apps would also need updating.
> None of this is to suggest that AOSP is necessarily bad or that people currently using AOSP phones should abandon them. AOSP derivatives like LineageOS, crDroid, Evolution X, /e/OS and GrapheneOS provide an invaluable service to people seeking privacy and greater software freedom, plus the ability to extend the lifespan of their phones.
I don't know anything about crDroid and Evolution X, but LineageOS and /e/OS in particular really don't offer people privacy. See the great blog posts from Mike Kuketz which you can translate to your own language about custom OSes and their privacy and security: https://www.kuketz-blog.de/android-grapheneos-calyxos-und-co... . Also, see the comparison of Android OSes by Eylenberg for notable security and privacy differences: https://eylenburg.github.io/android_comparison.htm .
The claim that custom OSes expand the lifespan of phones is often misleading. They need manufacturer support to ship driver and firmware updates and those are necessary to have a properly secured phone. You can't un-EOL a phone by putting a custom OS on it.
> If our goal is the empowerment and greater freedom of people, mobile Linux appears to be a more feasible route to achieve those goals in the long term than AOSP.
There is little empowerment if you can't really decide what you give apps access to.
Off the top of my head, here are some of the anti-user features in AOSP/Android that I would change:
* Remote attestation. If someone wants this, they can turn it one, but the OS and apps shouldn't be able to impose this requirement on the user.
* Making it hard for people to root their phones. I can understand having root access turned off by default, but it should be an easy and documented process to turn on root access on your phone, but it should also require setting a root password, which the user has to enter when doing an administrative action in the system. After rooting the phone, the GUI will ask for the root password when doing certain administrative tasks and the terminal will ask for it when using `su`. However, I would enable non-root users to access more than they currently can (see below).
* Apps should not be able to decide that they won't execute based on rooted status, Play Integrity checks, SELinux enforcing, bootloader unlocked status, etc. It should be up to the user, not the app creator, whether an app is allowed to execute. The OS should inform the user about potential security problems, but not encourage app creators to put these restrictions on their apps. I realize, however, that an AOSP fork wouldn't have the power to stop app creators from doing this stuff, so I would include a clean Android work profile and make it so those problematic apps can't detect what has been done to the rest of the system.
* The Activity Manager (`am` command) needs to be designed or eliminated to stop restricting the user. It is very annoying that users can't just execute graphical apps from the terminal like in Linux, and the way `am` does it is designed to make users not use a terminal. Instead of `am start -n org.videolan.vlc/org.videolan.vlc.gui.video.VideoPlayerActivity -a android.intent.action.VIEW -d file:////storage/emulated/0/VideoToPlay.mp4`, it should just be `vlc ~/VideoToPlay.mp4` like in normal Linux. Forcing apps to name the activity with the `-a` option, and to pass their parameters with the `-d` and `-es` options is designed to stop users from using options. Most Android apps have no command line options because Android makes it so painful to use them, and that is by design. Why does Android force users to refer to apps by reverse domain name order like "org.videolan.vlc" which is impossible to remember and so hard to type? Using the full reverse domain name for an app should only be necessary if there are two apps with the same name, and it should be possible to create an alias for apps so they can have short names. If a user (i.e. the person using the phone) initiates an app, then that person should be able to kill the app from the command line with a short command like `pkill app-name`. Currently, AOSP only allows `am force-stop com.example.myapp` if the phone has been rooted or if issuing through ADB (`adb shell am force-stop com.example.myapp`), which is an anti-user restriction that needs to be eliminated. I wouldn't require the `am` command at all for starting and stopping apps, but if AOSP/Android is going to use the `am` command, make everything easy to type and very short. It should be possible to set variables when executing apps just like in normal Linux (e.g. `MY_VAR=value myapp`) Instead, AOSP forces people to either root their phone or use adb, just to set variables when executing an app: `adb shell setprop wrap.com.example.myapp "env MY_VAR=value"`
* AOSP requires a rooted device or adb in order to use many commands, including `setprop`, the package manager (`pm`), most networking commands (`ip`, `ss`, `netstat`, etc.), use of wrap.com.example.appname or debug.com.example.appname, etc. It is really annoying that you have to root the device just to see the list of the installed packages with `pm list packages`, see the current battery state with `dumpsys battery` or even see the IP address with `ip a`.
* AOSP requires a rooted device or adb in order to view most of the directory structure on the device. In standard Linux, an ordinary user gets read-only access to `/`, `/dev`, `/sys`, etc., which makes it much easier to figure out how the system works and diagnose problems, but the device is basically a black box for the ordinary android user. I can understand forcing normal apps to access the hardware through the Android HAL and not be able to read the / directory, but terminal apps should have permissions, so the normal user can have read-only access to `/`, `/dev`, `/sys`, etc. Forcing users to execute some custom command like `termux-setup-storage` just to get permission to access the microSD card is bizarre and another anti-user feature.
* Forcing users to create an app just to execute a custom script from the launcher is another anti-user feature. Let’s say that you want tapping on an icon on your screen in order to run a custom script. In a standard Linux system, you just create the script, and then you add a launcher in the graphical interface to execute it or you add a `.desktop file` to the `~/.local/share/applications` to add it to the graphical interface. In AOSP/Android, you need to create your own app in Android Studio that has a `AndroidManifest.xml` file with this code: ``` <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> ``` And you need to have application code that has Java or Kotlin code like this: `Runtime.getRuntime().exec("/storage/emulated/0/your_script")` Then you need to create the apk file and sign it and install it. There are workarounds, like installing Termux and Termux:Widget, but those workarounds shouldn't be necessary. AOSP should make it as easy as standard Linux.
* The way permissions work in AOSP/Android is simply a hassle and requires too much cognitive load for the average user. When you first install a new app, you have no idea how the app works or what permissions it really needs. There are 324 different permissions in Android 17, and it is overwhelming for most people to install a messaging app and be asked for a dozen different permissions, such as Notifications, Identity, Contacts, SMS, Phone, Photos/Media, Storage, Camera, Microphone, Wi-Fi, Calendar and Location, which is why so many users simply grant all the permissions that are requested, so the permission system doesn't really work as intended.
It would be much better for the distro package manager to configure the app to grant just the permissions that most users of the distro would want, and then let the user set the permissions that she always wants to be asked about, but not be bothered with the rest. For example, Calendar and Location shouldn't be necessary for most users of a messaging app, so they wouldn't be granted by default, and the OS would ask for those permissions if the user tries to use a feature that requires those permissions. In a distro focused on security, the defaults would be different from a normal distro. The list of permissions granted by default should be shown to the user when installing, and users who want to pick and choose can open a dialog box to select the permissions. They can also set the permissions across all apps that they want to be asked about.
In my opinion, the user should only be asked about each permission only if an app comes from outside the default repository. Of course, this assumes that the default repository is only contains open source code, and the package manager is separate from the app creator and is reviewing the code in the interest of the AOSP distro's users.
* Each app has a different user assigned to it by AOSP/Android, and you can't change the name of that user, which is very inconvenient, because AOSP/Android creates random usernames that are very hard to remember. For example, every time I want to ssh to my AOSP phone, I have to open Termux and use the `whoami` command, because I can never remember that my Termux user is named u0_a281.
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 Linux won't be able to implement a better userspace security model without the help of the big Linux companies, then you may have a point. However, the example of Qubes demonstrates that it isn't impossible for a single distro to implement major changes.
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 into using OSes that aren't actually private.
It's also ridiculous that we are attacking anyone. Facts aren't attacks and 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 and violent and he has even attacked our supporters by calling them idiots and zealots. He even said that devices with strong privacy and security are for criminals and pedophiles. It's insane that someone in his position would even say such a thing.
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.
Linux distros and repos with AppArmor, SELinux, SNAP and Flatpak often decide what permissions the app has. It usually isn't the decision of the creator of the app. Of course, this can be done in the AOSP world, but I don't think F-Droid changes the permissions that apps ask for, and Google Play Store certainly doesn't change them in my experience.
Most Linux phones only run proprietary apps inside an LXC container (Waydroid, AppSupport, Andromeda or Lepton), which has its own security configuration that can be set the distro.
> Members of the GrapheneOS project (myself included) call these projects out because they're misleading their users.
It is fine to publicly criticize the security/privacy of other FOSS projects, because criticism often fuels improvement in the long term.
In my case, however, I had two public debates with Daniel Micay (first on a Hacker News thread, then later on a Reddit thread) about the security of Linux vs AOSP, in which he publicly accusing me of organizing raids against the GrapheneOS community, which was a total fabrication on his part. My interaction with Micay is mentioned in Techlore's 45 minute video, where he documents his own conflict with Micay.
I'm actually impressed by GrapheneOS's work on the Android kernel, so this isn't a comment on GrapheneOS per se, but I decided to never use GrapheneOS and to stay far away from the project based on that negative experience.
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.