Pixel 10 - Experimental support for GrapheneOS is now available!

3ch0

n3t_admin if they don't release it, wouldn't they affect all the manufacturers, not only GOS?

In my case, I have jumped the gun on a Pixel 10 Pro (contrary to @TheSmallestEvil in my case the 10 pro was way cheaper than the 9 pro, and I needed a new phone since mine is pretty banged up), so I'll patiently wait; I have a bit of hope that it'll end up released.

n3t_admin

3ch0 they can just share it privately in the same way they do with the security updates that were added by GrapheneOS as "optional" recently. So you would only be able to obtain the code if you were a certified Android vendor.

3ch0

n3t_admin hmmm I see. I'm guessing in that case the major OEM partner that they are working with is indeed a certified Android vendor, although they wouldn't be able to port anything from them to the Pixels.

Let's hope it doesn't go down that way

n3t_admin

3ch0 pretty much any OEM partner is a certified Android vendor (except Huawei and some others, I can't remember who else was on the blacklist). Just take a look at this list.

abednego

n3t_admin Perhaps what you say explains why Android 16 QPR1 source code is not available. IMHO, it may be related to the U.S. Government not allowing Huawei access to Android source code, instead of Google preventing Android-based operating systems that do not spy on their users (even if, obviously, a privacy-centered Android is against Google's business model).

Explanation can be as simple as U.S. Government trying to move Huawei and other blacklisted corporations out of the smartphone business.

Edit: I know GrapheneOS is more a secure operating system than a privacy-centered one.

n3t_admin

abednego I mentioned Huawei because it was banned in 2019, that's 6 years ago. Huawei has nothing to do with the current situation.
The current situation, if you look at the entirety of events, is rather a campaign to lock down Android as much as possible. We don't know who is responsible for it and if GrapheneOS is a direct target of this or simply collateral.

GrapheneOS

abednego

Edit: I know GrapheneOS is more a secure operating system than a privacy-centered one.

GrapheneOS is a privacy project above everything else. Our work on security is to protect privacy, so it's not a separate thing.

abednego

n3t_admin Agreed, but we cannot rule out the U.S. Government trying to lock out chinese smartphone manufacturers from accessing the source code.

You are right, we know nothing [yet] so GrapheneOS may be a direct target... time will say. However, it makes more sense to me (on a civilized world) considering those chinese corporations as adversaries rather than a team that develops a superb Android-based operating system with privacy and security as goals.

It would be sad if it is the latter, considering that —even if it being less profitable than a device that helps gathering information from their users— GrapheneOS helps increasing the selling of relatively expensive smartphones, a market area where iPhones are the clear winners.

Hardened hardware is important for some users, but it is nothing without an operating system that makes these devices truly secure, so Pixels + StockOS does not make a lot of sense to me. They are secure, but security is nothing without privacy.

I don't own a smartphone, just a Pixel tablet (although I'm now considering buying my first smartphone, after half a century, once we know what GrapheneOS will do in the next years, as I think it's the only operating system that actually makes sense for a private person). However, I'm pretty sure that, without GrapheneOS, the natural choice would be a high-end Samsung device, since the best security-oriented hardware is useless if it just runs an OS that spies on you.

Google knows that Pixels + GrapheneOS are pure synergy, so I would not expect GrapheneOS being the target of this odd movement on their side.

Edit: to me, we cannot have security without privacy; a device that leaks users information can hardly be considered secure. Let us say it this way: privacy is a subset of security, we can have the former without the latter (to some degree), but we cannot have the latter without the former.

n3t_admin

abednego Agreed, but we cannot rule out the U.S. Government trying to lock out chinese smartphone manufacturers from accessing the source code.

No, that has nothing to do with this.

I quote from Wikipedia, because I don't have much time to research myself:

From 2019 to 2024, versions 1 to 4 of the operating system were based on code from the Android Open Source Project (AOSP) and the Linux kernel; many Android apps could be sideloaded on HarmonyOS.[8] The next iteration of HarmonyOS became known as HarmonyOS NEXT. HarmonyOS NEXT was announced on August 4, 2023, and officially launched on October 22, 2024.[9] It replaced the OpenHarmony multi-kernel system with its own HarmonyOS microkernel at its core and removed all Android code. Since version 5, HarmonyOS only supports apps in its native "App" format.[10][11]

abednego Google knows that Pixels + GrapheneOS are pure synergy, so I would not expect GrapheneOS being the target of this odd movement on their side.

Not necessarily. We can only speculate and hope it does get released to AOSP eventually...

abednego

GrapheneOS GrapheneOS has an impressive security record for a project that is privacy centered above anything else!

I agree with you, privacy and security are not separate things. One can have some sort of privacy without security, but an insecure operating system cannot be a foundation for a truly private platform.

Allen

NeXTLoop I’m starting to fear this could be ended the same way as OpenSolaris in 2010 after the acquisition of Sun by Oracle.

abednego

Allen I certainly would prefer a GrapheneOS a few releases behind stock OS than an up to date stock OS that spies on us; not to say, proactive security on GrapheneOS would make those delayed releases more secure than a fully updated stock Android.

Allen

abednego Problem is that if Google stops pushing the source code to AOSP and they’ll provide it only to partners, it will be impossible for everyone to keep developing alternative OSes.
It is not a matter of staying few releases behind.
I don’t think the entire Android community has the strength to fork AOSP and keep the development without Google.

Nobody

Actually you can have security without privacy but you can not have privacy without security. As a general rule if security is broken privacy is also to some degree. These are all of course generalized statements.

Gold95

In LineageOS Changelog 30, they talk extensively about Google's New and Improved (for them, not you) AOSP now with 50% more barriers. It's the same stuff GrapheneOS has to deal with, so it's an interesting and relevant read. (Obviously they can't support Pixel 10 at the moment either.)

Google. Innovation through obstruction.

nandohyphen1

Gold95 Google. Innovation through obstruction.

Lol, too true

GrapheneOS

We've made significant progress on implementing Pixel 10 support based on the older release that's available for it. However, it's not something we can release for production usage and we need Android 16 QPR1 to be pushed to AOSP before we can do it properly. It won't take long to add Pixel 10 support once the port to Android 16 QPR1 has been completed after it's pushed to AOSP.

akc3n

Tuesday, November 25, 2025

We now have experimental support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold.

Our initial 2025112500 release for these is available through our web installer or releases page on our staging site:

https://staging.grapheneos.org/install/web
https://staging.grapheneos.org/releases#devices

X: https://x.com/GrapheneOS/status/1993492903851855981 / nitter

Sunday, November 23, 2025

GrapheneOS is currently developing Pixel 10 support and should have experimental releases available soon.

X: https://x.com/GrapheneOS/status/1992738736246067236 / nitter

Saturday, November 22, 2025

We're actively working on finishing support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold. It will likely be ready within a few weeks but we can't provide any specific timeline. It depends on which issues come up and how quickly we can get those resolved.

X: https://x.com/GrapheneOS/status/1992354529120338183 / nitter

Friday, November 21, 2025

Extremely likely to be supported before the end of the year.

X: https://x.com/GrapheneOS/status/1992001897121935818 / nitter

Monday, November 17, 2025

Our focus is Android 16 QPR1, then Android 16 QPR1 security preview releases with all the current December 2025 / January 2026 / February 2026 / March 2026 patches and finally support for all four Pixel 10 models.

X: https://x.com/GrapheneOS/status/1990581913338458328 / nitter

... We're working on support for the Pixel 10 devices but haven't completed it yet. Android 16 QPR1 is a requirement for proper support and was only released to the Android Open Source Project on Nov 11th. We're finishing that up.

X: https://x.com/GrapheneOS/status/1990461438843138228 / nitter

Wednesday, November 12, 2025

We're migrating to Android 16 QPR1 right now and will have an initial experimental release based on it soon.

X: https://x.com/GrapheneOS/status/1988739169548661005 / nitter

Tuesday, November 11, 2025

Android 16 QPR1 is finally being pushed to the Android Open Source Project. This should have happened on 2025-09-03. We migrated to full Android 16 QPR1 kernel code (GPLv2 tarball) and firmware in September. We couldn't migrate userspace to QPR1 without it being pushed to AOSP.

X: https://x.com/GrapheneOS/status/1988373959658905883 / nitter

It was needed for production Pixel 10 support for GrapheneOS. We still need to port to Android 16 QPR1 which is going to be a lot of work. We also still need to get done a bunch of work on our adevtool device support infrastructure before adding the Pixel 10 devices.

X: https://x.com/GrapheneOS/status/1988397511653175340 / nitter

Tuesday, October 21, 2025

GrapheneOS We've made significant progress on implementing Pixel 10 support based on the older release that's available for it. However, it's not something we can release for production usage and we need Android 16 QPR1 to be pushed to AOSP before we can do it properly. It won't take long to add Pixel 10 support once the port to Android 16 QPR1 has been completed after it's pushed to AOSP.

See comment#211.

Wednesday, August 27, 2025

We've received the Pixel 10 we ordered and have confirmed it supports unlocking, flashing another verified boot key and locking again.

Our Pixel 10 support will likely only be possible to complete after we finish porting to Android 16 QPR1 which is being released in September.

X: https://x.com/GrapheneOS/status/1960792610114511190 / nitter

Note: Thanks @wizoatk for providing the full quote in their comment#42 below.

Wednesday, August 20, 2025

It's much too early to ask us when we'll have support for the new Pixel 10 phones. They're only available for preorder. We need to have access to the devices and factory images before we can start working on this. If the new Pixels still provide proper alternate OS support, we can support them.

It will be significantly more work than usual to support the new Pixel 10 phones since Android 16 removed the Pixel device trees from the Android Open Source Project. However, that was already only part of what we need for device support and we worked around it by expanding our automated tooling.

We'll be able to use our automated tooling to support the new Pixel 10 devices as long as they still provide proper support for installing another OS with all of the security features supported. We have no reason to believe that's not supported anymore. It's just going to be significantly more work.

Pixel 10 also has much more significant hardware changes than the Pixel 6a through Pixel 9a we added easily. We don't know how long it's going to take yet. We can't estimate that until a while after we've started working on it. We can't start working on it until we have the devices and images.

Same thread on other platforms:

Bluesky: https://bsky.app/profile/grapheneos.org/post/3lwu2l5m7ws2d
Mastodon: https://grapheneos.social/@GrapheneOS/115062504680061630
X: https://x.com/GrapheneOS/status/1958244348119912839 / nitter

Related and recently locked threads to avoid duplicates are listed here for reference purpose:

VAULT

GrapheneOS

GrapheneOS The GOS Team commitment to its objectives is, as always, astounding. If only GOS was running the country too, what a world that would be!

VAULT

GrapheneOS Also more than happy to install / test Pre Release Trial versions and provide feedback!

Lolipop

GrapheneOS Thank you!

Bismark

Allen
Well whatever the dev's decide to do I will follow, if that means to the exit and onto some kind of Linux phone, then giddy up.

tarbeez

A bit late to the party but:

So with the release of A16 in June, Google:

Removed all specific device trees
Began pushing squashed commit history for kernel

And then when QPR1 dropped, they:

Didn't push source to AOSP in a timely manner, giving a vague time estimate
Have yet to push it or give updates on why

So since initial A16 release, the Grapheneos team:

Extracts binaries etc from A16 factory images
Recreates device trees for existing Pixels based on the published ones for A15
Plans to continue to do so for future releases (like QPR1) and has been adapting by developing tools to streamline this tedious process
Is attempting to partner up with a new OEM now that Google/Pixels are essentially just becoming another OEM with no special ease of use for devs?

Is this more or less right?

Are these device trees functionally identical or what? This must have been (and must continue to be) a huge effor, but has it led to any regressions in hardware support, or major bugs or drawbacks from a security perspective?

Will the (hopefully) new devices have all the security features that the latest Pixels have had, or are there likely to be some regressions or downgrades from a security perspective?

How will all this affect long term support currently supported Pixels? Are there too many unknowns still (why Google is doing this and what will happen with their releases going forward) to really know?

How much of a bind does this put grapheneos in? Or is it rather an opportunity to adapt, change, and expand? Are there any best/worst case of more/less likely scenarios for what Google is and will be doing with AOSP going forward?

newbie24689

tarbeez FWICT, you've provided a nice, concise summary of the state of affairs. Thanks!
I'm guessing the only question that you asked that could reasonably be answered is:

Are there too many unknowns still (why Google is doing this and what will happen with their releases going forward) to really know?

And I'd guess the answer is yes.
Sigh...I'd also guess there are many of us out here, ...quietly... waiting for (hopefully good) news .....

GrapheneOS

tarbeez

Began pushing squashed commit history for kernel

Only Pixel kernel driver repositories had a squashed history for the Android 16 release. They stopped pushing the tags to Git after Android 16 so we have to obtain tarballs from them instead, which they usually provide within a few hours during work hours.

Android's monthly updates ended and are now much smaller Pixel specific releases not pushed to AOSP so there have been no OS releases pushed to AOSP since Android 16 in June 2025, only security backports. Pixel device branches aren't going to be pushed either, which is why we need Android 16 QPR1 for proper Pixel 10 support in the first place.

Didn't push source to AOSP in a timely manner, giving a vague time estimate

It's not clear if it's a deliberate decision to delay it or AOSP being heavily deprioritized combined with the mass layoffs they've been doing to cut costs. It may be that they don't have people assigned to do it anymore. Android itself is on life support so this delay for AOSP may be caused by that rather than a deliberate decision to delay pushing tags for weeks/months.

Is attempting to partner up with a new OEM now that Google/Pixels are essentially just becoming another OEM with no special ease of use for devs?

We are partnered with a major OEM since June 2025 and are in the process of making the partnership more formal and advancing it. They've been doing work on their end. They've also been working on trying to help us work around the issues with AOSP.

Are these device trees functionally identical or what? This must have been (and must continue to be) a huge effor, but has it led to any regressions in hardware support, or major bugs or drawbacks from a security perspective?

The device support is better overall than what we had before via AOSP + our previous tooling and will get better. There were no security regressions. There's one issue which was introduced which is that charging mode doesn't always work properly anymore which is going to be resolved by a further round of device support improvements.

Will the (hopefully) new devices have all the security features that the latest Pixels have had, or are there likely to be some regressions or downgrades from a security perspective?

Both pros and cons, not one or the other. All of the requirements listed at https://grapheneos.org/faq#future-devices will be provided.

How will all this affect long term support currently supported Pixels? Are there too many unknowns still (why Google is doing this and what will happen with their releases going forward) to really know?

We should still be able to support Pixels until end-of-life. If AOSP ends, that's a problem for GrapheneOS as a whole rather than specifically for Pixels. If AOSP releases are delayed for 3 months, that's a bigger problem for Pixels than an OEM partner device because the Pixel driver/firmware releases will need to be nearly fully backported to an older major OS release which will involve a lot of work. We backported all the firmware and kernel drivers from Android 16 QPR1 but only backported specific parts of the userspace code based on where the Pixel security patches were for June 2025 and later. It would be quite difficult to do all of it and would require multiple new full time developers focused on this. If AOSP releases are delayed 3 months going forward, we can continue supporting Pixels, but it will be an ongoing major effort of backporting drivers/firmware.

How much of a bind does this put grapheneos in? Or is it rather an opportunity to adapt, change, and expand? Are there any best/worst case of more/less likely scenarios for what Google is and will be doing with AOSP going forward?

We'll be completely fine if AOSP quarterly/yearly releases start getting pushed on time again. We can do fine without Pixel device branches and device trees being in AOSP. We can also do fine without the monthly OS updates which are not Pixel exclusive updates since we can still get all of the security patches via the security backports combined with the Pixel factory images for firmware and userspace driver code. The kernel drivers are still fully available to us via the tarballs they provide. All of the changes they've made officially are completely tolerable. Only the unexpected Android 16 QPR1 is a major issue and it's not clear why that has happened, when it will be pushed or if it's going to happen for all major releases going forward. They've said they're going to push it but not when they'll do it beyond a "few weeks" on around September 10th. It's approaching 2 months, so hopefully that means it gets pushed soon and hopefully does not happen again for Android 16 QPR2 or later. If that doesn't happen again, the other regressions are really no big deal. We'll have gained a lot more via our OEM partnership than the insignificant stuff which was lost. If AOSP is discontinued as a whole, that's of course a huge problem and will heavily change the nature of the GrapheneOS project from what it has been up to this point.

« Previous Page Next Page »