Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We’ve made it clear we’re shipping Android 16 soon and that the supported devices will remain supported.
Pixels remain the only devices providing a high level of security combined with proper secure support for using another OS. We hope to have more options by the end of 2026 based on contact with an OEM interested in meeting our requirements but there’s no specific timeline.
Our very reasonable hardware requirements are listed at https://grapheneos.org/faq#future-devices. We expect industry standard security patches/features, not anything exotic. Multiple OEMs have indicated they should have no issue meeting these requirements with the next generation Snapdragon SoC.
In 2017, Pixel 2 added an off-the-shelf secure element (SE) with Weaver and insider attack resistance. Weaver provides aggressive throttling to make disk encryption work without a strong passphrase. Insider attack resistance means SE firmware updates require Owner user unlock.
Weaver has a key-value mapping with a slot for each profile on the device where providing the correct authentication token gets back a stored random token needed as an extra input for disk encryption. It’s a few hundred lines of code. It’s what makes a random 6 digit PIN work.
Most Android devices still lack a secure element providing Weaver, a StrongBox KeyMint and other standard functionality. Weaver was shipped by the Pixel 2 (2017) and StrongBox by the Pixel 3 (2018). It’s not a high expectation for devices to provide these features in 2025.
Most Android devices similarly lack proper privacy/security patches for drivers/firmware from day 1 and don’t provide long term support. It’s not a high expectation. OEMs get 1 month early access and should always ship Android Security Bulletin (ASB) and similar patches on time.
Pixel 8 and later provide 7 years of proper updates. Our minimum requirement is 5 years which has been the case since the Pixel 6. This requirement eliminates most devices despite us keeping it at 5 years. Getting security patches on time for 5 years isn’t a high expectation.
ARM provides standard exploit protections used by firmware and software to defend attack exploitation.
Pointer Authentication Codes (PAC) and Branch Target Identication (BTI) are near universal with ARMv9. Memory Tagging Extension (MTE) is more important and often omitted.
All of the standard ARM Cortex cores provide PAC, BTI and MTE. SoC vendors simply need to keep the security features intact and provide basic integration for them. OEMs need to do the same. We greatly expand usage of all 3 of these and were the first to use MTE in production.
MTE support launched with the Pixel 8 when it moved to ARMv9, but the stock OS still doesn’t use it by default. In GrapheneOS, we always use it for the Linux kernel and nearly all base OS processes including apps. We provide a toggle to enable it for all user installed apps.
We use it for known compatible user installed apps by default but it’s incredibly good at detecting memory corruption and uncovers a lot of bugs. Due to this, we integrated it into our user-facing crash reporting system and per-app exceptions can be made for user installed apps.
With Android 16, Pixel stock OS uses MTE for the small subset of users enabling Advanced Protection. It doesn’t use it for the kernel or most of the OS, only a small portion of the OS and a tiny number of apps marked compatible. The implementation is also much weaker than ours.
Our MTE integration is one of the biggest security features we offer. Qualcomm still hasn’t added MTE support, but it’s supposed to be available with their 2025 SoC launch. Exynos and MediaTek added it for flagships. Samsung integrated support for it as a development feature.
Snapdragon provides solid overall security. It includes a basic secure element for the flagships. Our expectation is Snapdragon will add MTE this year and OEMs willing to do the work of providing proper security features and patches can make devices meeting our standards in 2026.
The most secure non-Pixel devices disallow using another OS or don’t allow another OS to use important hardware-based security features. Samsung flagships would be the next best option if they didn’t do this. Our expectation is we need to work with an OEM, so we’re doing that.
GrapheneOS will continue supporting the current devices we support until their end-of-life dates. We’ll also add support for new Pixels as long as they meet our requirements. We’ve tried to make that clear, but recent posts about changes to AOSP have been widely misrepresented.
Prior to Android 16, Pixels had first class support in the Android Open Source Project as the official reference devices. This was never one of our requirements and no other device provides it. Many people are promoting hardware and software with atrocious security based on this.
A device without proper privacy/security patches or the hardware-based security features we expect didn’t become a better option due to Pixels losing something no other device has ever provided. There isn’t a non-Pixel device providing Android 15 QPR2 device trees let alone 16.
i’m happy this can remain an option.
Maybe it’s just me but those “very reasonable hardware requirements” look like they can be handled only by huge corporations directly involved with Android development.
If you expect to have stuff patched within a week, it should tell me you expect all those unpatched devices are going to be heavily impacted after a week. It doesn’t look like a lot of massive security incidents are happening to Android devices in recent years because some vendor delayed a patch by a week. I understand high standards, but if some user also expects high standards why shouldn’t they expect their devices patched within a day? Only explanation is that most people care about privacy risks much more than about security risks.
Security risks are privacy risks.
Security risks are privacy risks.
also vice-versa
Privacy risk is like “Google is constantly spying on me”. Security risk is like “a hacker next door is waiting for a next 0day to drop to get my passwords and photos”. Guess which of these is a real threat in most people’s eyes?
The friendly police officer wants to look at my phone: they’re going to attach it to an industrial device to hack into my phone and take all the data.
Every security risk is a privacy risk. Most people live in places where the police will investigate their phones, it’s not even rare anymore. Phones are examined at border crossings, arrests, everywhere.
If you are in such a position, it’s only a matter of time for a friendly police officer to stop being friendly as soon as he sees any signs of your phone using encryption, or GrapheneOS, or being Pixel. You will get detained/interrogated/beaten/etc. and you will share all your secrets yourself. If they have those industrial devices and you allow them to take your property from you - an OS will most likely not help you.
Instead of trusting OS to protect your data on your device from unauthorized users owning unknown toolset, it’s better to make sure you have no data they might want from you, on your device.
In most “free” countries digitally cracking or cloning phones or trying to scare the owner to unlock as well as remote exploitation is legal. Beating people up in interrogation rooms isn’t. Either way, GOS has a panic mode that will immediately erase the phone in a cryptographically secure fashion.
That’s too bad. It’s only a matter of time until there will be less countries that fit that “free” criteria then. Or the criteria itself will again shift further down.
Panic button implementation should not require that much and it should work fine on any device.
spyware is deployed remotely on journalist and protester phones… security is privacy.
So it’s an OS for journalists now? For protesters? I’m not going to trust an OS that failed to save anyone from Meta, to save me from my government.
Are all protesters notified they must buy a Google phone to protest safely?
GrapeheneOS failed to save you from meta? how?
Are there many android devices, with enough adoption to make development worthwhile, that aren’t made by giant corporations?
I meant the requirements are tailored to Google devices basically. Anyway, Google Pixels are about 5% of android market if I’m not mistaken. Is it worth it? If yes then I’m sure targeting pretty much any other maker would also worth it.
My advice: lower the requirements, and focus on real issues and real expectations from users. It appears GrapheneOS’s default settings were useless against that latest loopback tracking by Meta.
My advice: lower the requirements, and focus on real issues and real expectations from users
I do wish they would. I also hope that more relaxed OSes like LineageOS will adopt some of the common sense protections in GrapheneOS, like kill switch toggles for the microphone and camera.
GrapheneOS makes me feel fashionable, since I no longer keep a piece of tape over my phone camera.
It appears GrapheneOS’s default settings were useless against that latest loopback tracking by Meta.
Sure. But hopefully the intersection of folks running GrapheneOS and installing the Facebook mobile app is pretty small.
It doesn’t take a degree in Cybersecurity to be alarmed by Meta’s history, requested permissions, and Zuckerberg’s… Everything.
I don’t blame the GrapheneOs team for not spending a lot of time thinking I’m going to install an app developed by Meta.
