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.