GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Website: https://grapheneos.org/
Forum: https://discuss.grapheneos.org/
X: https://x.com/GrapheneOS
GitHub: https://github.com/GrapheneOS

Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

NIP-05 Address

[email protected]

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslp5jg4

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2026-09-13 01:32:16 GMT

Secure paste has been merged into GrapheneOS to provide a replacement for focused apps being able to read the clipboard:
https://github.com/GrapheneOS/platform_frameworks_base/pull/435

2026-09-12 19:22:07 GMT

- reply

Bitcoin's lack of on-chain privacy is a massive flaw. The mass surveillance enabled by the transparency blockchain is so far against the original ideals of the project.
Lightning doesn't provide strong privacy and isn't a solution to the lack of privacy in the Bitcoin base layer. Semi-centralized approaches as side chains aren't solving it either.
There's no fundamental blocker against Bitcoin implementing a shielded pool.

2026-09-12 16:29:25 GMT

- reply

It's important for GrapheneOS to get mainstream adoption and that means not ceding mainstream spaces to anti-GrapheneOS influence operations.

2026-09-12 15:13:51 GMT

Nearly all of the recent posts we've made on Hacker News are now being flagged which hides them from everyone by default. You can see this if you log into an account and enable "showdead" in your settings. Please vouch for our posts if you can do that.
https://news.ycombinator.com/threads?id=grapheneos

2026-09-11 01:49:56 GMT

- reply

People's conversations, thoughts and financial transactions have been largely private for most of human history. Law enforcement still managed to do their jobs. They can continue to do so in a world where privacy technologies preserve historical privacy norms.
We use and support open source projects working on restoring the privacy provided by cash including Monero. Moving from cash to credit cards, PayPal, etc. is an ongoing privacy disaster. Bitcoin and Ethereum currently are too.

2026-09-11 01:31:21 GMT

@npub19xk…6hgp GrapheneOS is an open source privacy project with a development team spread around the world. It exists to protect people from corporate and government surveillance.
GrapheneOS isn't a business and our legal entity is a Canadian non-profit organization.
GrapheneOS is entirely funded by donations. The majority of the donations are made via cryptocurrency.
We pay people an hourly rate set in USD or CAD. We currently pay around 14 people with Ethereum donations and 1 person with CAD.

2026-09-08 18:54:51 GMT

- reply

The developer creating the code is the author. They need to fully understand the code, rewrite whatever they generated with AI tools as necessary and take full responsibility for it. A tool they used to make it isn't who we consider the author. Creating a Git commit with an IDE resulting in the IDE claiming to be a co-author of the code is silly. It's a way of doing marketing via Git commit messages. We removed that from several small commits fixing minor issues someone submitted.

2026-09-08 18:07:22 GMT

- reply

We don't forbid using AI models for writing code but pull requests largely created that way will typically be rejected or skipped due to not meeting our requirements. It needs to be well written code which appears to be regular code written by a human regardless of the level of AI assistance involved in making it. It should not look like AI generated code. We do want to know if AI models are being used and how they're being used rather than people using it but not telling us they're using it.

2026-09-08 17:52:43 GMT

- reply

Going from having a working implementation of a feature to code we can merge often takes a long time. It can take months or even more than a year. It doesn't always work out. Sometimes we decide a feature ended up being too invasive or risky for other reasons and don't want to include it. We'll often do rewrites. Contributors need a full understanding of what they've submitted and need to be prepared to make substantial changes including fully rewriting it multiple times. AI slop isn't accepted.

2026-09-08 17:48:26 GMT

- reply

We have high standards for code being merged into GrapheneOS, especially for code in critically important parts of the project. Most of the changes made to the OS are to critically important parts of the code. It takes a long time to get features to meet our standards. There's usually a lot of back and forth review with many improvements requirements for anything significant. External contributors shouldn't try to take on major features without talking to us and planning that out with us first.

2026-09-08 17:43:19 GMT

- reply

We want people to report very serious Android Open Source Project security bugs to us but we can't handle a lot of minor issues. We don't generally need Chromium security bugs reported to us because they handle those far more quickly and have a far better system for releasing it. Linux kernel security bug reports are useful if they refused to fix it (arm64 kASLR) or it didn't get backported to the LTS. GKI LTS being behind the LTS is a separate problem we'll be addressing ourselves again soon.

2026-09-08 17:35:27 GMT

- reply

It isn't a good idea for people to point a model at an open source project and then start submitting bug reports to it. People need to be able to confirm the issues themselves with relatively high confidence before reporting it. It's okay to make some mistakes but it should not be the majority of what's reported. We do want people to report these kinds of security bugs to us but the signal to noise ratio is far too low right now. Even frontier models spew out contrived nonsense and fabrications.

2026-09-08 17:31:18 GMT

- reply

Frontier models are very good at finding bugs but it requires an experienced developer to babysit it and extract the useful portion of the output. Important bugs are often found but mixed in with a bunch of low quality output. The details on the issue and especially proposals to fix it are often wrong. It's still very useful and finds many real issues. The volume of real vulnerabilities being found this way in Linux, Chromium, Firefox, Postfix and countless other projects is quite scary.

2026-09-08 17:25:48 GMT

- reply

It can sometimes be useful to analyze an issue with an AI model but it usually isn't. It also definitely isn't useful to do it with a free or cheap model available without either paying for it or running it on very expensive hardware. In general, users do not have access to anything useful to analyze it. We don't want people to keep converting their issue reports into slop. We want what a user pasted into the AI model interface rather than what an AI model produced as output from that.

2026-09-08 17:11:11 GMT

GrapheneOS imposes a set of restrictions on how generative AI can be used in our project and community. It isn't forbidden but rather we imposed rules based on actual issues.
Posts made in our forum, chat rooms, issue tracker and the rest of our project must be written by humans. There's an exception from this rule for translation and accessibility features. That means commit messages, pull request messages, bug reports and feature requests are expected to be written by humans, not a machine.

2026-09-06 07:36:42 GMT

GrapheneOS version 2026090500 released:
https://grapheneos.org/releases#2026090500
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/41757-grapheneos-version-2026090500-released
#GrapheneOS #privacy #security

2026-09-05 06:26:31 GMT

Vanadium version 152.0.7977.84.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/152.0.7977.84.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/41725-vanadium-version-15207977840-released
#GrapheneOS #privacy #security #browser

2026-09-03 19:56:10 GMT

- reply

They want people to believe disk encryption and end-to-end encryption messaging don't work. They simultaneously claim not having mandatory backdoors prevents doing their jobs. They never had a near equivalent to mind reading before but now somehow private thoughts and conversations are unacceptable.

2026-09-03 19:48:34 GMT

- reply

These agencies want people to use sketchy products instead of GrapheneOS, iPhones and high quality end-to-end encrypted messaging apps. It's in their interest to mislead people into believing they should be buying sketchy devices with poor security whether or not they work with governments.

2026-09-03 19:45:04 GMT

- reply

Many European law enforcement agencies participated in this operation. Their operation put GrapheneOS developers at risk of being targeted by criminals by selling backdoored products as being based on GrapheneOS. Some of the people who purchased these harassed us due to baselessly blaming us for it.

2026-09-03 19:37:15 GMT

- reply

Operation Trojan Shield (ANOM) involved selling backdoored phones to criminals. These phones were regularly marketed as being based on GrapheneOS. In some cases, the marketing claimed the phones were GrapheneOS. Due to this, we had told people it was a scam before it came out it was a honey pot.

2026-09-03 18:39:00 GMT

- reply

Is isn't believable a device in Before First Unlock state with a strong passphrase had all of the data extracted without obtaining the passphrase elsewhere. It would mean the disk encryption algorithms themselves have been cracked. It's not the first of these stories where the details don't add up.

2026-09-03 18:20:17 GMT

We're aware of claims spread on German social media about GrapheneOS being exploited. We looked into it in case there was substance behind it. OS and hardware security isn't actually much of a factor in the story. Instead, the central claim is disk encryption with a strong passphrase can be cracked.

2026-09-02 02:20:26 GMT

- reply

Bluesky's character limit is tiny and these posts are written to fit in that limit because the Mastodon limit can't fit our entire thread in a single post. It's less than double of the Bluesky limit. It's a hard-wired limit with no configuration without patching it.
Convince Mastodon to add a higher character limit and we'll do the same thing we do on X where the paragraphs are sized for Bluesky but posted as single posts. This thread on X is 2 posts.
https://x.com/GrapheneOS/status/2094969085893181453

2026-09-02 02:02:03 GMT

- reply

Multiple Google engineers we've contacted have said they aren't able to give us any information about this so we're left doing reverse engineering and relying on leaks. The leaks do not seem reliable and do not match what we see. Our concern is that MTE may actually be broken due to CPU errata.

2026-09-02 02:00:16 GMT

- reply

Our initial testing indicates performance isn't substantially worse. The overhead may be higher but there was an incremental CPU performance with the Pixel 11 which should more than make up for it. However, MTE is unavailable with stable firmware and we're bypassing firmware disabling it for QPR2.

2026-09-02 01:56:45 GMT

- reply

There have been multiple leaks from Google including info published on news sites indicating hardware related to MTE was cut. There have also been leaks indicating it has performance issues and that's why it was initially fully stripped out at a firmware level firmware and is force disabled in QPR2.

2026-09-02 01:50:40 GMT

- reply

Android 17 QPR2 Beta 4 on the Pixel 11 force disables MTE for the OS from the firmware. Using it requires ignoring the arm64.nomte parameter being passed to the kernel. It still isn't clear why they're making the feature unavailable. SVE was also force disabled in Android 17 but not in QPR2 Beta 4.

2026-09-02 01:46:56 GMT

- reply

We've been testing performance of MTE on the Pixel 11 using the Android 17 QPR2 Beta 4 release adding back firmware support for it. MTE in asymmetric mode only has around 5% overhead in the standard benchmarks and other tests we've done. That's more than good enough but we've done limited tests.

2026-09-01 05:38:43 GMT

- reply

Android 17 QPR2 Beta 4 releases for the Pixel 11 series were only uploaded around 10 hours ago rather than with the initial release on August 28th so this hasn't been available for very long. It wasn't missed by us or people who looked into it after our initial thread but rather wasn't out yet.

2026-09-01 05:30:21 GMT

- reply

See https://grapheneos.social/@GrapheneOS/117194007157499435 for updated information. There's at least minimal hardware support for MTE on the Pixel 11. We think they likely fully disabled and removed it from firmware due to a major performance downgrade caused by the removal of hardware for accelerating it.
#note1uv4…5mj2

2026-09-01 05:25:28 GMT

- reply

Google has been increasingly silent in response to our communications since dropping Pixel support from AOSP with Android 16 in June 2025. They could have told us MTE performance was significantly reduced so they disabled it at launch but will add it back to firmware for QPR2. That's still unclear.

2026-09-01 05:19:57 GMT

- reply

If the issue is simply that MTE performance is poor, then we can support the Pixel 11 with the major caveat that it will be a significant performance downgrade. Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models.

2026-09-01 05:15:50 GMT

- reply

We reached out to multiple people at Google asking about the MTE situation on the Pixel 11 prior to making our original thread and didn't receive any responses. We still don't know what's wrong with MTE on the Pixel 11. It isn't clear if there are serious CPU errata or it simply performs very badly.

2026-09-01 05:10:30 GMT

- reply

We expect performance must be quite bad for Google to have decided to entirely strip out support for it in not only the software but also the firmware so that no would could even try to use it before Android 17 QPR2 Beta 4. That's a very strange thing to do. It's at least added back to firmware now.

2026-09-01 05:08:08 GMT

- reply

It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. We're in the process of determining whether it's fully functional and the performance characteristics. It's likely disabled due to performance being ruined.

2026-09-01 05:02:34 GMT

- reply

Android 17 QPR2 Beta 4 was released on August 28th. It's the first Beta release with Pixel 11 support. MTE support is still completely disabled in the OS and arm64.nomte is unconditionally passed by the firmware to the kernel. The good news is the firmware itself had MTE support added back to it.

2026-09-01 04:57:14 GMT

We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.

2026-08-30 15:56:40 GMT

- reply

GrapheneOS doesn't support the repair mode if that's what you're talking about and it's a security liability. People can back up their data and install the stock OS if that's truly needed but it shouldn't be.
We've always avoided using the Android modding community's "custom ROM" term since it's inaccurate and propagates misconceptions. It makes things seem more complicated and messy than they are. There are a bunch of ROMs including the SoC boot ROM but the OS isn't one.

2026-08-30 14:44:24 GMT

- reply

Google's customer support are highly unreliable source of information and often need to have someone higher up overrule their incorrect decisions.
Some of our community members asked about the lack of MTE on the Pixel 11 and got answers clearly derived from LLM output from people who nearly certainly hadn't heard of MTE before. That includes claiming post-quantum cryptography and the Titan M3 somehow make MTE unnecessary or that the September update will supposedly add it.

2026-08-30 14:40:19 GMT

- reply

Installing GrapheneOS doesn't void the Pixel warranty and doesn't prevent using Google's official repair services. It never says it voids the warranty when unlocking and it wouldn't be legal in many of the countries where it's sold. It isn't an official Google policy for it to void the warranty but rather the official policy is that it's still support. Some of Google's customer support people are misinformed and make inaccurate claims as part of trying to close tickets.

2026-08-30 14:40:05 GMT

- reply

2026-08-29 18:41:41 GMT

- reply

Pixel 8 still has many years of support remaining and is more secure overall than the Pixel 11 anyway. They're nearly as secure as the Pixel 10.
Pixel 11 does have the Titan M3 but using a strong passphrase with our 2-factor fingerprint unlock feature for convenience avoids depending on the secure element for encryption. Post-quantum secure verified boot via ML-DSA is a nice improvement with the Pixel 11 but it doesn't matter right now and probably won't in the next 7 years either.

2026-08-29 18:37:57 GMT

- reply

It's possible to support it but it would go back to not having MTE as is the case for 6th/7th gen Pixels. It's a lot more secure than 6th/7th gene Pixels but it's missing the main security improvement introduced since those were the current devices. Not having MTE is a huge security downgrade for GrapheneOS. We aren't sure what to do about it. It's nice it has post-quantum secure verified boot and the new Titan M3 which is likely a lot better but it doesn't make up for MTE.

2026-08-29 18:11:10 GMT

- reply

Motorola Signature (2026) has a commitment to 7 years of support. That was the initial potential device for us to support but didn't end up having MTE. Various other features also need to developed. The initial device we'll be supporting will be the successor to the Motorola Signature (2026). We fully intend on providing 7 years of updates for it and doing a better job than we can do for Pixels based on having official driver/firmware access we can ship when Qualcomm, etc. schedule it.

2026-08-29 16:18:24 GMT

- reply

Yes, 'a' series Pixels provide all of the same security features and 7 years of updates. They're much better value too. The 'a' series devices mainly downgrade camera and display quality. Pixel 10a used the previous generation SoC so the CPU performance is lower than the same generation devices but the GPU is about the same. It upgraded to the much better cellular radio used by the non-a Pixel 9 series devices and other Pixel 10 devices. Pixel 10a pricing is very good for what you get.

2026-08-29 16:02:13 GMT

- reply

We haven't determined what to do about this situation. It may be best for us to skip the Pixel 11 series devices. We can shift our focus entirely to the upcoming Motorola devices instead. Pixel 10a was really a 9th gen Pixel, so hopefully the Pixel 11a does the same with 10th gen and includes MTE.

2026-08-29 15:58:42 GMT

- reply

We strongly recommend against buying Pixel 11 devices. Pixel 8, 9 and 10 have much better overall security for GrapheneOS. Pixel 10 is cheaper with similar hardware and MTE. Pixel 11's Titan M3 should improve BFU security for users without a strong passphrase, but losing MTE craters AFU security.

2026-08-29 15:45:35 GMT

- reply

Compared to the stock Pixel OS, GrapheneOS ships AOSP patches months earlier and Linux kernel patches many months earlier. However, we rely on them for firmware and most driver updates. We also want to move to new kernel branches earlier. These things can be improved with our Motorola partnership.

2026-08-29 15:35:03 GMT

- reply

Pixel 9a and earlier (including Nexus devices) were the Android Open Source Project reference devices. Pixel support was removed from AOSP with Android 16. It's now harder to support Pixels than many other devices and massive progress towards open source firmware and driver libraries was discarded.

2026-08-29 15:14:50 GMT

- reply

Compared to the Pixel 11, a Snapdragon 8 Elite Gen 5 has ~40% higher single threaded CPU performance, ~80% higher multi threaded performance, over 100% higher GPU performance and a far better cellular radio. It also finally has MTE. The next gen is what will be in the first Motorola with GrapheneOS.

2026-08-29 15:08:17 GMT

- reply

Pixel 11 series is a lot more expensive for an incremental improvement to the CPU, the same underpowered GPU and reduced RAM for the Pro base models. They finally caught up to the last generation of Qualcomm cellular radio. It's overpriced, the upgrades aren't impressive and losing MTE is appalling.

2026-08-29 14:56:38 GMT

- reply

Pixel 11 does have security improvements including moving to post-quantum secure verified boot (ML-DSA) and replacing Samsung Shannon IMS with AOSP IMS. Titan M3 should significantly improve protection against data extraction in Before First Unlock state. It's too bad they ruined it by cutting MTE.

2026-08-29 14:51:27 GMT

- reply

Neither iOS or Android encourage app developers to opt into MTE and other more aggressive security features used in the base OS. Apple's docs warn developers of performance and stability issues. Even Signal doesn't opt-in. Our approach enables forcing using MTE in the standard allocators regardless.

2026-08-29 14:46:56 GMT

- reply

Apple's MIE and Android 16+ AAPM don't use MTE for user installed apps unless those explicitly opt in. GrapheneOS enables it for more apps automatically and has a toggle for users to opt-in for every user installed app. There's a per-app toggle to opt-out for incompatible apps which is uncommon.

2026-08-29 14:40:34 GMT

- reply

Apple's Memory Integrity Enforcement (MIE) is an always enabled feature on the iPhone 17. It's simply a high quality implementation of MTE using the latest standard extensions. It uses MTE in the most secure mode in the kernel and a large portion of userbase. They did a very good job integrating it.

2026-08-29 14:36:10 GMT

- reply

Pixel 8 launched with hardware MTE support in October 2023. We integrated it into our hardened_malloc project and began using it across the OS later that month. Android and the Pixel OS never started using it by default. Android Advanced Protection Mode in Android 16 enables it for a few processes.

2026-08-29 14:29:34 GMT

- reply

ARM hardware memory tagging (MTE) is used by GrapheneOS across the entire base OS including the kernel and every standard base OS process. It's only temporarily disabled for a few device-specific processes. It greatly improves protection against nearly all remote exploits and many local exploits.

2026-08-29 14:27:00 GMT

- reply

Pixel 11 doesn't have MTE support. It's entirely gone.

2026-08-29 14:19:30 GMT

We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.

2026-08-28 15:15:36 GMT

- reply

Chromium extensions are similar to Android accessibility services in terms of the access they have available within the browser. Extensions can access nearly all user data and make changes to content. It's highly problematic especially since it lacks a decent permission system. For the most part, extensions have to be granted all the permissions they require at install time. The permission system also isn't well designed from a privacy perspective. Extensions also lack site isolation.

2026-08-26 00:50:25 GMT

Vanadium version 152.0.7977.64.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/152.0.7977.64.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/41465-vanadium-version-15207977640-released
#GrapheneOS #privacy #security #browser

2026-08-24 19:29:47 GMT

- reply

The privacy features added by GrapheneOS protect against privacy invasive behavior by apps, services and networks.
GrapheneOS does not trust networks. It fixes various standard Android VPN leaks which makes using a high quality VPN work much better.
You're stating VPN services track users as a fact when not every VPN service does. There are also multi-party VPN implementations which can be used to avoid trusting any single provider.

2026-08-22 21:09:16 GMT

- reply

The devices will have a decent secure element. It will provide the latest Android 16 QPR2 rate limiting design and other features. It won't be missing any important functionality but we don't expect the initial iteration to have comparable hardening against attacks as the Titan M2/M3. It will get better over time. It already appears Qualcomm is making major improvements for the next gen SoC but we don't know all details yet. It's getting better though.

2026-08-22 17:49:01 GMT

- reply

The current generation Motorola devices don't meet our requirements. It's a subset of the next generation ones which will meet our requirements. We pointed to the Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) as an example of what's coming. The current Signature is the predecessor to the upcoming device we're working on them with and we should be able to support the horizontal and vertical folding flagships with very similar hardware to that afterwards.

2026-08-22 17:35:22 GMT

- reply

It isn't feasible to provide a secure element on the same level as Pixels in the near term. Titan M2/M3 are incredible and it's going to take time for a solution from Qualcomm or another vendor to catch up. Qualcomm's QSEE is a TEE similar to Pixels using Trusty OS, Qualcomm SPU is a secore core similar to the Pixel secure core but they didn't have a direct equivalent to the Titan M2/M3 and OEMs just reused a eSIM/NFC chip from NFC in practice.

2026-08-22 17:33:47 GMT

- reply

Pixels are now very difficult to support. It's harder to support Pixels than it would be to support many other devices not doing more than publishing kernel sources. We use Pixels because they have the best hardware, firmware and software security among Android devices. As we said in the original thread though, it's very possible to do better than Pixels at security in many areas and we fully intend to do that with the Motorola devices.

2026-08-22 17:32:05 GMT

- reply

It was difficult to simply add support for the Pixel 10a after launch despite already having 9th/10th gen Pixel support. Pixel 10a is really a refresh of the Pixel 9a with the 9th gen Pixel SoC rather than a true 10th gen Pixel. Still, the way it launched with a quirky device branch not matching the standard AOSP releases led to it being problematic for us to support. We had to work around a lot of issues causing various crashes, etc. due to mismatches.

2026-08-22 17:30:57 GMT

- reply

We don't know if it will be feasible to support 11th gen Pixels prior to Android 17 QPR2 or even Android 18. Android 17 QPR2 was already well into development with public Betga releases available for a while already. The changes for 11th gen Pixels may not be rolled into it and that may happen with Android 18. It's certainly possible to add support with only Android 17 but it's way harder and we haven't determined if we're going to need to wait yet.

2026-08-22 17:29:44 GMT

- reply

Traditionally, newly launched Pixels would come with a device branch being pushed to AOSP. That was often based on a newer revision of the development branch than the existing devices. They also often add new features to AOSP for use on the new devices and those often initially appear in the device support branch. It makes it problematic to try to support the devices until the next major release pushed to AOSP has this all rolled into it.

2026-08-22 17:28:29 GMT

- reply

We can continue supporting all of the earlier Pixels. We added 10th gen Pixel support after Pixels were dropped from AOSP and should be able to do the same for 11th gen Pixels. However, it can be extremely difficult especially before the next major release of the OS is pushed to AOSP. For example, Pixel 11 moved to post-quantum-secure cryptography for verified boot and added it for hardware keystores. We need to figure out if it shipped in AOSP already.

2026-08-22 17:25:05 GMT

- reply

We also made substantial upstream contributions to both the Android Open Source Project ad the upstream projects of it. We made substantial contributions to Pixels through the vulnerabilities we reported and suggestions we made too. There are multiple hardware and firmware security improvements which were based on what we reported or suggested. For example, Android's key attestation supports key pinning instead of just root-based verification now.

2026-08-22 17:23:41 GMT

- reply

It's very much in Google's interest for us to support their devices and for it to be a good experience. Google does many misguided things which aren't in their interest.
GrapheneOS currently has around 500k users. Nearly all of those people bought Pixels to use it. Many of them bought one or more previous Pixels they used before their current device.
GrapheneOS is not an anti-Google project and they earned plenty of money selling hardware for it.

2026-08-22 17:22:11 GMT

- reply

Motorola and Qualcomm are going to be helping with fixing the bugs uncovered by using hardware memory tagging across the kernel and userspace instead of us having to do all of it.
Adding support for more devices is still going to be hard but we have a lot of help and don't have to do everything ourselves. It should be a lot easier to do ongoing porting to new major releases and maintenance for the Motorola devices than Pixels once it's launched.

2026-08-22 17:21:14 GMT

- reply

Here are a couple examples of us having to reverse engineer and reimplement code for Pixel specific features:
https://github.com/GrapheneOS/platform_packages_apps_Settings/pull/434
https://github.com/GrapheneOS/platform_packages_apps_Settings/pull/390
It's far more than this and we have to do this kind of work to simply add basic support for the devices.
We're also on our own having to fix issues uncovered by hardware memory tagging, etc.
Motorola is going to be giving us everything we need for AOSP and is helping port our features.

2026-08-22 17:18:34 GMT

- reply

The purpose of the tooling has greatly expanded to needing to entirely create AOSP support for Pixels ourselves by reverse engineering the stock OS factory images. We also greatly expanded what it handles for configuration. It reverse engineers the configuration and compiled resources to set all of that up properly. We also reverse engineer the Java code ourselves to implement Pixel specific features not present in AOSP such as the higher PWM toggle.

2026-08-22 17:17:21 GMT

- reply

They no longer provide the setup for building AOSP for Pixels or the userspace driver / service code for them. We use automated tooling we developed in partnership with ProtonAOSP and have continued for years after ProtonAOSP developed stopped. The original purpose of the tooling was adding all the missing configuration and building Pixel userspace driver/service code from source instead of simply using the prebuilt code as they suggested to people.

2026-08-22 17:15:33 GMT

- reply

Instead, we have to request the kernel driver sources via a Google Forms setup (https://source.android.com/opensourcerequest) and they provide a link to the tarballs for the specific tag we requested. They throw all the code from dozens of Git repositories into a single massive tarball with no commit history. It can't be uploaded to GitHub as a single repository due to size. It also breaks uploading to GitLab even with our free Enterprise so we had to split adding files.

2026-08-22 17:13:48 GMT

- reply

It's possible that it will take us months to support the new Pixel 11 devices because of how hard it is to add support for them now. We used to be able to add support for the newly launched devices in under 24 hours from receiving them and the code being pushed which was done on launch day. Prior to Android 16, Pixel 11 devices would have had all of their kernel sources and a large portion of the userspace sources pushed to AOSP in a device branch now.

2026-08-22 17:12:35 GMT

- reply

We sometimes have to exclude a few processes from hardware memory tagging when there are invalid memory accesses occurring during regular use. For open source code, it's at least feasible for us to figure it out and fix it. We have to do that for anything caught in the kernel in practice, but for userspace processes we decide if it's worth doing based on the importance of the process. It's too hard to fix in Pixel userspace driver HAL processes now.

2026-08-22 17:10:57 GMT

- reply

Google has hardware memory tagging for a tiny set of processes as part of Android Advanced Protection Mode (AAPM) added in Android 16. They don't use it for the kernel, don't use it for the vast majority of AOSP userspace processes and don't use it for the device-related processes in the vendor HAL. They also don't use it for apps not explicitly opting into it which are negligible. We use it for the whole kernel and userspace including all base OS apps.

2026-08-22 17:09:46 GMT

- reply

A substantial part of our resources is spent on developing and maintaining support for making production builds of AOSP for Pixels. There's also a large portion of our resources used on making our hardening features work on Pixels. A subset of our features are hardware-based including hardware memory tagging, USB-C port protection and others. Hardware memory tagging also uncovers a massive number of memory corruption bugs in software in practice.

2026-08-22 17:08:26 GMT

- reply

Pixel 9a and earlier were officially the Android Open Source Project (AOSP) reference devices. It included official support for them including the sources for the kernel drivers and a large portion of the userspace device support code. They didn't have things set up for proper production builds with the vendor code built from sources so we had to put that together ourselves.
Android 16 removed support for Pixels from AOSP and we had to develop it again.

2026-08-22 17:00:26 GMT

- reply

Our users often import Pixels to other countries and in some of those they still have those features marked as disabled for most carriers. The features usually work when simply force enabled so we added a way to do it. It's not forced by default since it may not work and we don't want to have broken mobile data and calls by default. It works with most carriers without those already enabled and users can easily figure out if it works with basic testing.

2026-08-22 16:58:53 GMT

- reply

It works well with it.
By default, GrapheneOS works with all of the carriers supported by the stock Pixel OS. GrapheneOS adds a carrier overrides feature usable to force the availability of 5G, VoLTE, VoNR, VoWiFi and cross-SIM calling. This means GrapheneOS can be used with those features on carriers in countries where Pixels aren't available and haven't done compatibility testing to mark those as available. It makes it work better globally.

2026-08-22 16:51:17 GMT

- reply

We want it to be possible to buy the regular variant of the devices and install GrapheneOS on those to avoid depending on the availability of devices sold with GrapheneOS. These details all need to be worked out once it's closer to ready.

2026-08-22 16:36:21 GMT

- reply

It hasn't been decided how selling devices with it will work. We definitely want people to be able to buy the regular variants of the devices and install it themselves to make sure it's widely available though.

2026-08-22 16:31:53 GMT

- reply

We aren't getting funding from them and don't particularly need it. They're assigning engineers to work on porting GrapheneOS to the devices and maintaining it once that's done which is what we need. We want them to assign more engineers to it rather than giving us money.

2026-08-22 02:31:40 GMT

- reply

Used Pixel 8a and Pixel 9a are what we're recommending to people as budget devices. It's also possible there are cheap Pixel 8 devices available too. They've got tons of update support time remaining so we can keep recommending them for quite a while. We'll likely stop recommending them once they reach only 3 years of updates remaining but they're nowhere close to that yet.

2026-08-22 02:29:17 GMT

- reply

Pixel 'a' series devices get 7 years of updates from launch. Pixel 8a launched in May 2024 so it has updates until at least May 2031. Buying a used 'a' series Pixel can be as cheap as those but comes with proper updates and security protections.
Pixel 8 and later meet our full set of official security requirements including hardware memory tagging and a very good secure element with everything expected. That includes the Pixel 8a. 6th/7th gen Pixels aren't recommended anymore.

2026-08-22 02:04:54 GMT

- reply

Pixel 10a base price is $499 and it's often on sale for 15% off. It has the same 7 years of support from launch as the flagship devices. Older 'a' series devices are often available very cheaply on sale. It's not currently feasible to provide a competitive budget option with strong security. We'll still have Pixel support and for now those are the budget option via the 'a' series especially by getting used devices.

2026-08-22 02:03:25 GMT

- reply

Only once those can provide at least 5 years of proper updates, hardware memory tagging, proper secure element integration and the other requirements.
Qualcomm has the best security features and most modern code for the flagship chips. It takes time for it to trickle down to the lower end chips.
Non-Pixel OEMs also typically don't provide updates nearly as frequently or for nearly as much time for the lower end devices which would need to change for us to use those.

2026-08-22 01:48:27 GMT

- reply

Supporting a flip device with vertical folding would be a new form factor for GrapheneOS. The main use case for those is a tiny phone to use with one hand in the folded form factor. The tablet-style folding devices we already support are extremely useful for web browsing, reading, maps, etc.

2026-08-22 01:45:36 GMT

- reply

We do plan to support Motorola's Razr Fold and Razr Ultra (flip) devices in addition to a regular device. We already support the original Pixel Fold (Pixel 7) along with the Pixel 9 Pro Fold and Pixel 10 Pro Fold. We still plan to add support for 11th gen Pixels including the Pixel 11 Pro Fold too.

2026-08-22 01:33:38 GMT

- reply

T-Mobile will definitely work fine. We haven't heard of people having issues with this in the US though, only certain countries like Australia and Turkey.

2026-08-22 01:29:46 GMT

- reply

We had to heavily overhaul how we support Pixels including reimplementing the userspace part of our USB-C port protection feature in the standard Android USB code instead of integrated inside of the Pixel USB HAL. It still works fine and we didn't really lose any features but we can no longer build most of the vendor code ourselves with extra compiler hardening. It makes it harder to resolve issues like memory corruption bugs found by MTE too. It sucks.

2026-08-22 01:28:24 GMT

- reply

They removed support for Pixels from AOSP with Android 16. Pixels had largely open source userspace device support code and were even moving to a lot of the firmware being open source. With Android 16, they completely stopped pushing any of it to AOSP. Only the Pixel kernel driver code is still available and it requires filling out this form and waiting for them to share a link to a Google Drive folder with tarballs for a tag:
https://source.android.com/opensourcerequest

2026-08-22 01:26:12 GMT

- reply

It's quite possible the successor to the Motorola Signature will be available in the US. If it wasn't then it could be imported. Many of our users are importing Pixels to countries where they aren't available via a package forwarding service in the US, EU or elsewhere. It's how we get phones to some of our developers too.

2026-08-22 01:13:40 GMT

- reply

If they sell the Motorola Signature (2026), Razr Fold (2026) and Razr Ultra (2026) then the 2027 devices we're supporting will probably be available.
We don't know how the RAM and SSD shortage will impact the availability and pricing though.

2026-08-22 00:57:30 GMT

- reply

No, since we need the security improvements in the upcoming devices and will have our hands full supporting those.