grapheneos

Many of the GrapheneOS features including Contact Scopes, Storage Scopes, Sensors toggle and things most users can understand and are very interested in having. Most of what GrapheneOS provides is under the hood which is a good thing for usability but there are plenty of features non-technical users can see and understand.

Installing sandboxed Google Play is done by simply pressing the install button for it in the GrapheneOS App Store.

Android itself is shady as heck

In what sense is anything shady about the Android Open Source Project (AOSP)?

WiFi and SIM card chips are compromised right out from the factory

This is an unsubstantiated claims not only lacking evidence but heavily contradicted by a large amount of available evidence. It also has nothing to do with Android.

People are usually OK with options like postmarketOS (non-Android) or with the most popular distros like LineageOS. Some jump to things like SailFishOS (attention: russian financial hands on that one).

postmarketOS and the desktop software stack it uses is far less private and secure than AOSP.

SailfishOS isn't open source like AOSP and is far less private and secure than it. It combines many of the worst aspects of desktop operating system security with low-end Android device security.

LineageOS is another fork of AOSP but doesn't preserve all the standard updates and privacy/security protections.

None of those are a hardened OS greatly improving privacy and security compared to the baseline of AOSP. None are as private and secure as unmodified AOSP. Those aren't in the same space as GrapheneOS.

Even a cheap chinese smartphone with their "stock" Android can argue for being less shady and raise less attention to yourself than a distro which forces you into specific poisoned hardware. That is just dumb.

You aren't backing up your claims of hardware being compromised with evidence. You're also not being specific about what it is you consider to be a problem. You have an issue with us using Pixels. Does that also apply to the upcoming Motorola Mobility (Lenovo) devices too? Which specific hardware do you think would be okay to use? We need hardware meeting our requirements for updates and hardware-based security features which is why Motorola needs to improve their devices to meet our requirements. GrapheneOS also needs extensive porting work to devices due to the hardware-based security features and the need for drivers/HALs to be made compatible with the exploit protections.

There's a lot of evidence showing governments need to develop or purchase exploits for iPhones and Pixels. There's no evidence of there being any hardware backdoors.

It is also suspicious the preferential treatment given to that suspicious distro while all others are left in the dark.

We don't receive any preferential treatment from Google. Android's business side disallowed us from receiving any form of partner access and took away the security patch preview access given to us by Android's security team. That has been the case for years. We have security preview patch access but it isn't from either Google. Google also hasn't ever allowed us to have early access to major Android releases but that doesn't mean we haven't obtained it.

Using hardware from a vendor that cannot be audited and every possible business interest in spying you.

You can claim this about any hardware. Pixels meet our hardware requirements and we're expanding support to multiple upcoming Motorola Mobility (Lenovo) devices meeting our requirements. There will be a growing number of Motorola devices with official support for GrapheneOS.

Same excuse argued by Signal

GrapheneOS has never received any government grants and is fully funded by donations. Signal didn't cover up that they were received Open Technology Fund grants and other government money.

It is easy to be transparent about donations rather than opaque: publish the operating costs and level of donations by a certified auditor without need to disclose names.

The entirety of the GrapheneOS funding comes from donations. Our finances are audited every year as a requirement for a Canadian non-profit receiving more than $500k/year in revenue. The purpose of the audits is nearly entirely to make sure we're spending all of the money. It makes sure that all the money is accounted for and being spent appropriately. A subset of our expenses are specifically checked to make sure of it. It also involves more than that but it has little to do with where the donations are received from. Donations are largely made anonymously. We can see names for Wise and PayPal donations but they're often not the legal names of individuals or companies. Most donations are received via cryptocurrency.

We can publish information on our revenue and expenses but it's not clear what that has to do with the unsubstantiated claims you're making about us or why it would stop you from doing it.

But you won't, strangely enough.

You weren't responding to anyone that's part of the GrapheneOS project.

It's a ROM (in the phone sense)

There are multiple ROMs involved but GrapheneOS isn't one. There's an SoC boot ROM which loads SoC firmware from the SSD, verifies it and transfers control to it. The littlekernel-based firmware stage which loads GrapheneOS isn't a ROM. GrapheneOS and most of the SoC firmware are simply stored on SSD partitions. There are A/B partitions for both the SoC firmware and the OS on the SSD. Installing (flashing) GrapheneOS involves writing out images to those partitions on the SSD and erasing an existing data partition which also happens as part of unlocking or locking the device. Those partitions aren't read-only from an OS perspective. Verified boot secures what's stored on those, not any form of hardware or firmware level write protection.

There are also boot ROMs for other hardware components. Many of those are responsible for receiving firmware uploaded by the OS to the hardware component at boot, verifying it and transferring control to it. The secure element has separate persistent firmware with a separate verified boot process since the OS isn't allowed to update it until the Owner user has successfully authenticated so it needs persistent firmware. Other hardware components mostly don't need persistent firmware and it's more secure if they don't have it.

it's not stock

GrapheneOS will be available as the stock OS on multiple Motorola Mobility devices based on our partnership. It won't necessarily be available as the stock OS when the official support for it launches since it's not one of the minimum requirements but it's planned.

so installing it is a customization

It's a separate OS forked from the Android Open Source Project but this terminology gives many people the incorrect impression that it's a modification of the stock OS. It leads to many people asking questions about what it removes from the stock OS and believing we removed Google integration when that was never present in the baseline. There are a lot of misconceptions which are propagated by this terminology. We don't use it and think it only serves to create unnecessary confusion and misconceptions.

In what way is it not a custom ROM?

It was just never accurate terminology for forks of the Android Open Source Project on modern devices. The terminology originates from phone modding prior to Android and there was a time it made sense. It hasn't made sense for a long time.

It takes around 10 minutes to install it. Most of the time people spend on it is deciding how they want to set things up. It's very easy to set it up in a similar way that you would use the stock OS. You can use a single profile with sandboxed Google Play installed.

Many people want to segment things more than that by having a dedicated profile for apps depending on sandboxed Google Play. A work profile, Private Space or secondary user can be used for it. A work profile or Private Space is a lot more convenient. Using a work profile avoids wasting the Owner user's Private Space if you want to use it for sensitive data. We want to add support for multiple Private Spaces per user in the future instead of only 1 per user to fully obsolete work profiles for local usage.

It doesn't have to be new. They'll permit using an Android 8 to 10 device last updated over 6 years ago or a similarly old iPhone.

There are a bunch of companies selling devices with GrapheneOS at a significant markup despite it being very easy for non-technical people to install it themselves in 10 to 20 minutes. There's a lot of demand for it and companies set prices based on what they can get away with charging.

The linked post is a mess which was probably generated with an LLM. GrapheneOS does have useful properties for this even though it isn't the focus. Someone could write a proper article making a case for it even though this isn't one.

GrapheneOS is free and we recommend people install it themselves with the web installer. People can also save a lot of money getting a used device, but we strongly recommend against an older device than a Pixel 8 due to support time. A used Pixel 8a tends to be the cheapest option. An important thing to watch out for with used devices is avoiding ones which were originally sold by carriers locking their devices. Some phone sellers wrongly label locked devices as being fully unlocked.

If people buy a device with GrapheneOS instead of doing it themselves as we recommend, we a guide to follow to make sure it's genuine GrapheneOS and get rid of any strange software or configuration it ships with:

https://grapheneos.org/faq#preinstalled-devices

ADB can be used to disable it without GrapheneOS by disabling the packages providing the high level implementation of wireless emergency alerts. It's not something most people can be expected to do though. It's actually a lot easier to install GrapheneOS via the web installer than using the CLI ADB shell. ADB is also quite dangerous and people can be tricked into giving very invasive access to malware with it. We're not recommending that people use ADB for this but rather just noting it can be done.

GrapheneOS supports fully disabling wireless alerts via the Settings app. It's possible to disable it on other Android devices via ADB.

GrapheneOS supports fully disabling wireless alerts via the Settings app. It's possible to disable it on other Android devices via ADB.

That sounds like an NSO-level attack, right?

There are many tiers of far easier remote attacks far easier than exploiting an up-to-date iPhone through iMessage of WhatsApp. It doesn't mean that's what happened but it's often not something that's extremely difficult. Many people use phones with years of missing security patches. It's getting increasingly easy to exploit those in the age of LLMs.

Regardless, it sounds more like a social engineering attack tricking someone into installing an invasive app and granting invasive permissions to it.

I doubt abusers routinely pull that out?!

They do regularly use social engineering to trick their partners into setting up stalkerware or permitting it to be installed. Getting a new phone and accounts is a very helpful for people who are victims of it. They've often given access to their accounts and devices without knowing how to fully get rid of it. Reclaiming the existing devices and accounts is far easier if they have a clean one to start from where they can get technical help. It doesn't specifically need to be a GrapheneOS device, but it's a good choice in general and doesn't require being technically savvy to use or even install it.

So I'm assuming Graphene is at least as strict as that?

GrapheneOS is a privacy and security hardened OS. LineageOS and CyanogenMod aren't in that space. GrapheneOS preserves the standard privacy and security features and updates of the Android Open Source Project as a baseline. It greatly improves privacy and security with major privacy and security features along with much better privacy/security updates. It keeps up with the major OS updates including having a release based on Android 17 since the day it was released (2026-06-16).

Can someone explain this? I've used custom ROMs back in the day (Cyanogen!) but I'm not familiar with GrapheneOS.

GrapheneOS is a production quality OS with around 15 people paid to work on it. It's not a hobbyist project. We've never used the term custom ROM since it isn't accurate and propagates misconceptions. It's best to avoid it.

The article mentions that an abuser could put spyware on your phone? Is that a realistic scenario?

Yes, stalkerware is very common and there are a bunch of apps marketed for this purpose. It's helpful to get a new phone set up from scratch without the same accounts or automatically restoring any data on it. This can be a GrapheneOS phone but it doesn't particularly need to be. It's not GrapheneOS recommending itself for this purpose. There are an assortment of privacy and security features relevant to this in standard Android 17 and in the features added by GrapheneOS but nothing essential to this. GrapheneOS makes sense as a general choice for a new phone for many people due to being a highly usable, compatible, private and secure device but we're not specifically recommending it for being who are victims of stalkerware ourselves.

Getting a new phone is very useful to someone that's a victim of a controlling partner but it doesn't particularly need to be a GrapheneOS device. GrapheneOS has features useful for this including Auditor and standard Android profiles (Private Space, secondary users) with improvements but we're not specifically recommending it for this ourselves. People who are victims of this probably just need a new phone of any kind and to prioritize other things.

and 5-10x the price of an older, but still perfectly useful degoogled phone from Marketplace

Devices with drastically worse privacy and security than the Android Open Source Project including lack of bare minimum updates aren't in the same space as GrapheneOS.

It's generally better for people to install GrapheneOS themselves since it's very easy and saves a lot of money. It takes 10 minutes to install GrapheneOS with the web installer. It also avoids needing to trust a company to do it, although it's possible to verify an install done by someone else is genuine with the verified boot key fingerprint and/or Auditor. An existing install by someone else should be factory reset it to avoid any sketchy configuration.

It's generally better for people to install GrapheneOS themselves since it's very easy and saves a lot of money. It takes 10 minutes to install GrapheneOS with the web installer. It also avoids needing to trust a company to do it, although it's possible to verify an install done by someone else is genuine with the verified boot key fingerprint and/or Auditor. An existing install by someone else should be factory reset it to avoid any sketchy configuration.

Getting a new phone is very useful to someone that's a victim of a controlling partner but it doesn't particularly need to be a GrapheneOS device. GrapheneOS has features useful for this including Auditor and standard Android profiles but we're not specifically recommending it for this ourselves. People who are victims of this probably just need a new phone of any kind and to prioritize other things.

There's no risk of bricking a device by using the official GrapheneOS web installer and it takes 10 minutes. Devices can also be purchased with GrapheneOS installed.

Aside from that, GrapheneOS isn't read-only memory firmware and that incorrect term should be avoided since it propagates misconceptions.

They're making inaccurate attacks on GrapheneOS to mislead people. We have sponsorships for our server infrastructure with those companies listed here:

https://grapheneos.org/sponsors

We also list the sponsors of specific servers in our server documentation:

https://grapheneos.org/articles/grapheneos-servers

Four of our sponsors are dedicated server companies and one is a VPN company sponsored 2 dedicated servers for us via one of their dedicated servers providers where they have a large discount on the hardware and traffic.

IPinfo is a well known GeoIP company. They provide open source projects including Alma Linux and GrapheneOS with free access to geolocation database downloads. We use it to implement GeoDNS on our self-hosted anycast DNS clusters. They get most of their GeoIP data from crawling the internet with over 1300 probes which makes it far more accurate than the more traditional options based on WHOIS and geofeeds.

What's sketchy about any of these companies? They also don't receive anything more than being listed on our site which we would do for transparency regardless.

GrapheneOS is entirely funded by donations but other donations by both companies and individuals are informal rather than official sponsorships. For example, Proton and Cape have both repeatedly made donations to GrapheneOS.

Only hardware that supports bootloader relocking are Pixel devices

That's not quite right, but Pixels are the only devices providing all of the hardware requirements for GrapheneOS listed here:

https://grapheneos.org/faq#future-devices

GrapheneOS will also support future Motorola devices meeting all of these our requirements and providing official GrapheneOS support. Those will likely be available in under a year.

I can't say anything about VPN affiliation, but everything else is complete bollocks.

Mullvad and Proton have both sponsored GrapheneOS with donations. All they wanted was us to say they donated to us which we would do for transparency anyway. We have no obligation to ever post about it again or to say anything positive about either company.

They're describing Tor as a government sponsored VPN and are claiming we promoted it because we answered people's questions about using it on GrapheneOS and have a small amount of documentation on using it. We don't specifically promote using Tor. We regularly caution people about the risk of making themselves into targets with it by accessing the public internet via exit nodes. Tor makes sense for some situations but we generally recommend using a traditional VPN for most people's use cases.

suspicious sponsors

GrapheneOS is entirely funded by donations. It doesn't accept strings attached sponsorships. We list companies sponsoring infrastructure for GrapheneOS on our website to encourage more companies to make donations and for transparency.

https://grapheneos.org/sponsors

Which of these companies do you claim is suspicious and what's the reasoning for that? Server sponsorships are how many Linux distributions including Alpine, Arch and Debian host their update mirrors and other infrastructure.

force users into opaque hardware

Computer hardware and firmware is nearly universally closed source. The devices we currently support are among the most open including using Trusty OS for the TEE and secure core, OpenTitan as the basis for the secure element and littlekernel for the late stage boot chain on the main SoC.

GrapheneOS is coming to more devices but those devices need to meet our hardware security and requirements and provide the driver/firmware updates we need. We have a partnership with Motorola Mobility that's working towards new devices meeting our requirements with official GrapheneOS support.

just the other day they were also promoting the usage of government sponsored VPNs

This is utter nonsense. Answering people's questions about how to use Tor on GrapheneOS is not promoting government sponsored VPNs. We don't even specifically promote Tor but rather explain how to use it. We also recommend people carefully consider using it to access the public internet via exit nodes since it makes people using it into targets and anyone can host an exit node.

What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?

It's definitely planned for GrapheneOS to be sold preinstalled on devices, but it will also be possible to buy devices without it and install it yourself with our web installer. The details need to be worked out. The focus is currently meeting the requirements and porting GrapheneOS to the devices.

It's not accurate, see https://news.ycombinator.com/item?id=48767176.

giving the option to completely block attestation and DRM API would be a good start.

Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.

GrapheneOS does provide a toggle to block apps using the Play Integrity API because we found a small subset of apps using it are not yet enforcing providing a result due to being in the process of phasing it in. This doesn't apply to DRM or direct use of hardware attestation. We have a planned feature for blocking access to DRM as an attack surface reduction feature since it can eliminate a little bit of OS attack surface and a significant part of the TrustZone attack surface. Hardware key attestation has almost no attack surface and doesn't provide any info not available other ways.

this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.

That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue. That's why they made a point of how they separated the systems for it, but you don't have to trust that on GrapheneOS. If you use a VPN it's irrelevant.

the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.

That's not an accurate description. It's also implemented via our server by default too. If you use a VPN that's not relevant.

The MediaDRM ID is also widely misunderstood since it is scoped per-app rather than being global. The best way to address it is our planned DRM toggle.

if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos

We disabled DRM provisioning and usage by default in Vanadium years ago and have a publicly visible feature planned for providing a toggle for native apps being able to use it. We don't have unlimited resources to get everything we want quickly implemented.

how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?

You're making attestation and DRM key provisioning sound far worse than it is. It's not fingerprinting and it doesn't give them another way to track users in practice. If services want to share data with Google then they don't need any of this to do it and it doesn't inherently result in anything being shared with them that's in any way useful. We have a planned feature for providing a DRM toggle but it's nearly entirely wanted for security, not privacy, and there are bigger security features to implement. There are many planned privacy features which would make a major impact rather than near zero as this would.

Preventing fingerprinting by websites is a very hard problem especially considering things like using timing and performance measurements for it. That's going to be a priority for us. Doing it for native apps would require a massive amount of changes to get anywhere close to websites. We could add 100 features reducing fingerprinting for native apps without accomplishing anything significant. We're focused on privacy features with a larger impact.

Linux based mobile OS foundation

AOSP is a Linux-based mobile OS. It runs fine on top of standard Linux kernels without downstream changes. Getting rid of the need for closed source userspace drivers for components like a modern Mali GPU can be done with AOSP and will benefit the most people that way. AOSP if many companies and others band together to do it. It could also happen due to government intervention due to Google's antitrust law violations, but that could be done poorly in a way that harms open source.

System administrators of a traditional Linux distribution assemble their own OS out of their package and configuration choices. There isn't a well defined standard base OS. That's part of what makes it the traditional approach and is inherently incompatible with the privacy and security approach of AOSP or iOS in many ways.

Linux distributions use different implementations of init systems, shells, command-line tools and nearly everything else. Ubuntu uses glibc, systemd and Rust uutils coreutils. Alpine uses OpenRC, Musl and BusyBox as the defaults. Debian uses glibc, systemd and GNU coreutils as the defaults but supports other choices of init system. Each has their own variants of the projects they each package with different versions, patches compile-time configuration and default runtime configuration.

Using systemd, Bash, etc. on an OS Debian is a choice for the system administrator rather than the OS being defined that way. Even if people swap out major components for ones which aren't officially supported, it's not generally regarded as not using the distribution anymore. It's a far different approach than defining a standard base OS, developing that together as a whole with user installed packages and configuration changes are solely on top of that.

The higher up you go in the software stack, the more different things are across operating systems. The Debian installations across different machines are a vastly different OS with far different components and configuration. There are default sets of packages and configurations but not a standard base OS shared across each machine. Swapping out components and changing the configuration isn't making it not Debian and is pretty much required.

A huge portion of server Linux uses musl and BusyBox due to Alpine.

Embedded Linux has always heavily used different software stacks. Android wasn't much different in that regard on mobile. Android runs fine on standard Linux kernels without any mandatory downstream changes. It was never the only distribution making changes to the kernel regardless.

prioritised privacy

Privacy depends on privacy patches/protections and on security patches/protections. They do the opposite of taking it seriously from the hardware through the software.

None has anything close to the privacy or security of AOSP or iOS. Librem 5 is the direct opposite of hardware prioritizing privacy and security. It doesn't provide basic firmware updates, uses a bunch of extremely low security components and brings the awful privacy and security of a desktop OS to mobile on top of that. It's the opposite of how you're describing it. Purism's devices also aren't open source as they claim but rather are closed source hardware with closed source firmware. They only pretend it's open hardware and firmware by not shipping the closed source firmware with the OS, which leaves users without crucial privacy/security protections. The components don't have proper updates available regardless due to their hardware choices but they don't ship what is available and prevented doing it for some components.

They target devices made with the intent of running linux, but also have a few ports to android devices.

AOSP is a Linux distribution. Linux doesn't mean glibc, systemd, GNU coreutils and GNOME. If you mean GNU/Linux or bringing systemd to mobile then that's what you should say.

There isn't a standard Linux distribution. Those operating systems have drastically worse security than a decent server distribution or the mainstream mobile Linux. Traditional Linux distributions don't have a standard set of core components or configuration so system administrators are assembling their own OS and the differences in security are vast. It's extremely rare to deploy anything close to the level of iOS and AOSP security but it's an entirely different environment on a server. Running a few server applications in weak sandboxes is far different than using a bunch of apps including an enormously complex web browser with a GPU, cellular, Wi-Fi, Bluetooth, NFC, etc. There's also no serious attempt by almost anyone to defend Linux servers and desktops against physical attacks with the disk encryption only even attempting to provide protection for data before the encryption passphrase is entered, not after.

Those ports of desktop Linux to mobile don't have a proper privacy/security model for running applications. They don't have anything close to modern exploit protections or hardware-based security features crucial to protect against increasingly sophisticated and widespread exploits. AOSP is a Linux distribution with drastically improved privacy and security compared to a traditional desktop Linux traditional. GrapheneOS starts from there and improves privacy and security much further.

Usability-wise, they are no match for Android and iOS—or even versions of them from five years ago.

They're also no match for the privacy or security of iOS or AOSP. They're bringing the lack of privacy/security model and protections on desktop operating systems and hardware to mobile. It's a massive regression for privacy and security despite being marketed in the opposite way.

Waydroid is a container-based approach to boot a full Android system on regular GNU/Linux systems running Wayland based desktop environments (like PureOS).

No, it's only a partially working form of Android with the privacy/security model largely disabled and poor app compatibility. Waydroid is based on an ancient release of Android and disables the SELinux-based privacy/security model. It doesn't contain apps from each other and has far less protection for the Linux kernel from the apps. It has poor app compatibility and isn't a good approach to running Android in another OS. ChromeOS made a proper better Android container not losing the privacy/security model but migrated to using hardware accelerated virtual machines. It makes a lot more sense to use a VM since current era smartphone hardware fully supports it.

PureOS also provides convergence via Phosh. Convergence means here that the same app can be used on a phone and on a big screen, the GUI adjusts to the available screen size.

Android Open Source Project has a desktop mode. It has a hardware-based virtualization layer for running desktop Linux applications too including GPU acceleration support.

Phosh aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux.

Android runs fine on mainline Linux. It doesn't require special kernels. That's tied to specific hardware rather than Android.

PureOS has far worse privacy and drastically worse security compared to iOS or AOSP. It's bringing the traditional atrocious privacy and security of desktops to mobile. Librem 5 also combines that with extraordinarily insecure hardware missing basic firmware updates and security protections. As a whole, these make it drastically easier to exploit devices. That includes going back to disk encryption which doesn't work for the average user due to them not using a strong passphrase and not protecting against data extraction with physical access unless the device is turned off.

It doesn't solve the current issue

These operating systems aren't compatible with most of the apps and services people want to use. It's going to become much worse. The compatibility layers several provide have extremely poor compatibility combined with disabling the Android security model and app sandbox. Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more.

Aside from that, many people care about privacy and security. Each of those operating systems is far less private and drastically less secure than the Android Open Source Project. None has a truly complete and working app sandbox or permission model. None uses modern exploit protections. None has serious hardware-based encryption features needed to protect against data extraction. They're not serious alternatives to an iPhone from a privacy and security perspective as an AOSP-based OS on decent hardware can be.

but in case we don't manage to push back on this

It's a warning that's being added to Google Mobile Services operating systems. It doesn't negatively impact other operating systems based on the Android Open Source Project.

various actual linux OSes for mobile

Linux doesn't mean GNU/Linux or systemd/Linux. It doesn't at all imply using glibc, systemd, GNU coreutils, Bash, GNOME, etc. Distributions using different userspace components including several of the ones you've listed are still Linux Android-based operating systems including AOSP and GrapheneOS are Linux distributions. Alpine doesn't use glibc and SailfishOS has a lot of their own mix of open and closed source software. Using a typical desktop Linux userspace stack isn't what makes it Linux and there's also not a lot of consistency in what's used on desktops regardless. A Linux distribution not using musl, glibc, GNU coreutils, etc. is still Linux.

There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.

AOSP-based mobile operating systems are Linux distributions.

and they are legally allowed to fingerprint grapheneos and block Play functionality.

No, and you also don't understand how the Play Integrity API is implemented.

Google has a bunch of monopolies tied to Android. Antitrust laws put limits on what they're allowed to do which Google has been egregiously violating for many years.

Google isn't legally allowed to pull a bait and switch with Android by changing it away from an open platform and open source project. They used Android being both of those things to build and expand monopolies in a bunch of areas. The way Google exerts control over OEM partners with Google Mobile Services licensing has already been found to be illegal in multiple countries and they're in the process of losing more court cases over it. South Korea found their terms to be highly illegal and Samsung is already largely free from their restrictions.

Play Integrity API enforces the Google Mobile Services licensing model. The licensing model and terms are highly illegal in countries with decent antitrust law. It has already been found to be illegal by the courts in multiple countries. EU and US have particularly strong laws where they're egregiously violating and that's going to have consequences.

Play Integrity API is primarily based on hardware attestation, which is not fingerprinting. The strong integrity level fully requires hardware attestation and services using it are migrating to enforcing that. Device integrity level requires hardware attestation for devices known to have a working implementation which is a major loophole but it's gradually being closed. Play Integrity API also has many software checks.

Play Integrity API software checks require having an immense amount of privileged access which means it's not very compatible with sandboxed Google Play without an immense amount of work which would achieve nothing. Tricking all the software checks won't make it start permitting GrapheneOS. It's not feasible to pretend the device is one without hardware attestation while avoiding it being detected that it's being faked. None of this can be feasibly bypassed in the long term without it repeatedly breaking and becoming increasingly impractical to bypass. Many apps already require hardware attestation via the strong integrity level and eventually Google will close the loopholes for the device integrity level.

maybe once that happens grapheneos will finally take anti-fingerprinting seriously

It isn't fingerprinting and no amount of anti-fingerprinting will bypass it. Hardware attestation exists and it provides the device model and OS. It's also easy for apps to detect those in many ways. Apps can just look at their own memory and see the OS libraries loaded into them. The only way to pretend to be the stock OS even without hardware attestation would be making essentially no changes to anything since apps can look at a lot of OS libraries, etc.

Running apps in VM wouldn't solve anything either and will only work for apps which don't try to detect being in a VM and don't use hardware attestation or the Play Integrity API. We'll still need to support running apps on bare metal once we have VM isolation features since one of the main things apps doing these anti-tampering and attestation checks is trying to block is being run in a virtual environment.

GrapheneOS uses all of the standard Android security features including hardware-based security features. It also adds major security improvements including features heavily based on hardware security features which are either entirely unused or barely used by AOSP or the Pixel OS. Heavily using hardware memory tagging, integrating our USB protection with the USB controller and other features are core parts of what makes it GrapheneOS. An incomplete port without all the standard security features or the GrapheneOS added security features isn't GrapheneOS.

GrapheneOS closely follows along with Android releases, Linux kernel LTS revisions and driver/firmware updates. It had an experimental release based an Android 17 after only 2 days of it being released earlier this month. It quickly made it through our testing process with many regressions resolved to our Stable channel. This is part of what makes it GrapheneOS and an incomplete port to another device without the same updates wouldn't be GrapheneOS.

GrapheneOS is open source. People can make an incomplete port of GrapheneOS to other devices using their own project name. It's not a port of GrapheneOS to another device without having all the features and updates.

We phase in new hardware requirements for standard security features and the older generation devices without those are eventually gone. Adding a new device without hardware memory tagging would be far different than still supporting 6th/7th gen Pixels without it since we strongly recommend against buying those devices anymore and they're going to end up end-of-life.

The main issue is that OEMs make too many device models with unnecessary variations for carriers/regions and make too many changes to AOSP. It's extremely hard for them to properly maintain all of it.

Qualcomm offers up to 8 years of updates from platform launch. Getting around 7 years of updates requires OEMs to use the latest and great platform combined with paying Qualcomm a lot of money for long term support. It may cost a million dollars or more for each year of support. OEMs also need similar support for other components but that mostly means choosing decent components.

Providing proper updates has a cost most OEMs haven't been willing to pay. Pixels and Samsung flagships have been the exceptions. Samsung doesn't properly update most devices, only flagships, and it's still worse than Pixels in important ways. Samsung has also been closest to having all the hardware-based security features we need but doesn't let us use a lot of those due to crippling devices if they're ever unlocked.

Our partnership with Motorola Mobility partly involves them improving their devices to meet all of our requirements which was already largely happening. It also requires porting GrapheneOS to their devices and fully supporting Snapdragon again including having hardware memory tagging support on it for the first time. No one is currently using hardware memory tagging in production on Snapdragon let alone for the entire kernel and userspace as we do so it's going to be a lot of work. Motorola is going to be helping with all of this. They're also going to provide us more minimal hardware support code without unnecessary changes not needed for AOSP / GrapheneOS. A bunch of GrapheneOS features need to be ported and the device support code needs to be made compatible with our changes too including but not limited to fixing memory corruption bugs.