Which features specifically do Fairphones miss? It seems to me like most of those requirements are all part of the (mostly open-source) software stack. The Fairphone uses a standard Qualcomm chip that should work as well or as badly as a Pixel SoC.
The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" part isn't even true for Pixels.
Fairphone no secure element, no hardware memory tagging and lack the expected security patches. It's missing some of the other features too. Our list is about hardware requirements and firmware/driver requirements, not the AOSP portion of the OS.
> The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" part isn't even true for Pixels.
That's not correct. Pixels also ship the monthly, quarterly and yearly OS updates rather than the Android Security Bulletin backports to older releases. Android Security Bulletins are backports of High and Critical severity patches to the initial yearly releases from the past several years. Stock Pixel OS and AOSP have a new release each month and often ship those patches before they're backporting.
Android Security Bulletins also include a small subset of SoC vendor patches, but the remaining SoC vendor patches and other hardware component patches also need to be provided as part of meeting our requirements.
>The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" part isn't even true for Pixels.
Doesn't the ASB get published at the same time as pixel updates? So by definition it's up to date.
> Doesn't the ASB get published at the same time as pixel updates? So by definition it's up to date.
Android Security Bulletin are standalone backports of High and Critical severity security patches to older initial yearly releases. Those older releases are currently Android 13, 14, 15 and 16. They're not the full security patches. Many backports included in the ASB were often included in the stable OS updates a month or two earlier.
There are 2 officially supported paths for updates:
1) The path taken by Pixels of shipping each monthly, quarterly and yearly OS release in the month they come out, which they always do unless something goes very wrong and an update is pulled without them having a replacement ready. It's extremely rare for them not end up rolling out the latest OS release to users.
2) The path taken by most non-Pixel OEMs where they stick with an initial yearly release and apply Android Security Bulletin backports, eventually moving to a new initial yearly release. Pixels have never really used this, with the exception of the Pixel 8a and Pixel 9a launching on a branch of the previous quarterly release and then moving to the regular OS releases with the next quarterly/yearly release. That's a special case at launch from them saving resources.
GrapheneOS follows the Pixel path and would need to make that work on hardware not doing it if we supported it. That would mean dealing with issues created by relying on the forward compatibility system (Treble) and not having improvements to the device support code tied to newer Android releases. Our hardware requirements require that this would work and that they would be providing the OS updates for the lower level code without a huge delay.
Using older code below the OS layer would also mean not building it with the OS but rather separately, and would imply that it's probably a lot more closed source than Pixels were.
Yes, but vulnerabilities don't always get backported to older (supported) devices immediately. I distinctly recall one case where an Android CVE was patched months later on one Pixel model compared to the others that were in support. However, because search engines have all become terrible in the age of AI, I can only find vague references.
I myself regularly find my Pixel only noticing updates half a month later unless I manually check while my Samsung tablet notifies me immediately once my quarterly update is available. It's quite annoying to have to check for updates manually every week, but I suppose updates are technically available.
GrapheneOS has no specific requirement for the Titan M2. It requires a secure element providing the standard AOSP secure element features which are provided by other devices such as recent Samsung Galaxy devices. Fairphone doesn't provide a secure element. Snapdragon provides a basic secure element in the flagship SoC but not every SoC, and it doesn't necessarily provide all the required features without the OEM doing work. There are more requirements than a secure element. It's best to look at the official list of requirements at https://grapheneos.org/faq#future-devices.
The tech is impressive, but not exactly Google exclusive. If the ROM developers intend to only support devices with Pixel exclusive features like the Titan chips, they might as well say they're not interested in supporting non-Google phones.
GrapheneOS has no specific requirement for the Titan M2. It requires a secure element providing the standard AOSP secure element features which are provided by other devices such as recent Samsung Galaxy devices. Fairphone doesn't provide a secure element. Snapdragon provides a basic secure element in the flagship SoC but not every SoC, and it doesn't necessarily provide all the required features without the OEM doing work. There are more requirements than a secure element. It's best to look at the official list of requirements at https://grapheneos.org/faq#future-devices.
GrapheneOS is actively working with a non-Google Android OEM towards their devices officially supported GrapheneOS and it's certainly something we're interested in providing. Existing non-Pixel devices with proper support for using another OS don't meet our hardware security and update requirements.
As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.
This is a misunderstanding. It's just that Google Pixel are the only devices that have this level of hardware security engineering AND are open to thirdparty roms like grapheneos to a decent degree.
Samsung Flagships and Iphones seem to have similar level of security engineering in them (Pixels use Samsung CPUs essentially) but aren't open to the required degree for third party roms.
There's nothing else on the Market that delivers on that Level. The GrapheneOS guys are working with someone one a potential custom phone to get the required level of hardware security but nothing has materialized. Companies like Fairphone are free to deliver hardware that is competitive in the security space and i'm sure that the grapheneos team will consider them then. But until anyone else does i'll keep buying whatever phone grapheneos wants me to buy, i don't care.
> Samsung Flagships and Iphones seem to have similar level of security engineering in them (Pixels use Samsung CPUs essentially) but aren't open to the required degree for third party roms.
Samsung has devices providing all of the major security features listed at https://grapheneos.org/faq#future-devices and they could easily add the couple things they may be missing such as reset attack protection. The issue is that they don't allow another OS to use a bunch of the hardware-based security features.
Samsung devices aren't on the same level as Pixels in terms of quality of implementation for security, but they would meet our security feature requirements if they let us use the security features.
Whether Samsung's security update approach meets our requirements is a different story. They do provide long term support but it isn't necessarily what we expect. There are often long delays even from the beginning and they tend to switch to doing the security updates with months in between for older devices. Huge delays for yearly updates and not shipping the monthly/quarterly updates is an issue too since we'd be running a newer OS version on top of components from an older one, relying on Treble for compatibility, which is likely to cause issues and therefore delays. We can accept having to use Treble that way but it would be significantly harder to provide the OS updates as quickly as we expect.
As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.
> The GrapheneOS guys are working with someone one a potential custom phone to get the required level of hardware security but nothing has materialized.
The current OEM we're working with started working with us in June 2025 so it hasn't been a long time. The previous OEM went bankrupt, but this is a larger and more established company.
The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" part isn't even true for Pixels.