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.
> 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.
Doesn't the ASB get published at the same time as pixel updates? So by definition it's up to date.
I did, for instance, find a case where Google Project Zero published a blog post on a vulnerability while their Pixel 6 was still four days away from the first updates: https://9to5google.com/2023/03/20/pixel-6-march-2023-update/
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.
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.
I suspect it's the features of the titan m2 security chip. It's a pretty cool piece engineering [0].
[0] https://www.androidauthority.com/titan-m2-google-3261547/
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 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.
Thanks for giving me a freedom respecting alternative to Google and Apples duopoly.
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.