zlacker

>>madars+(OP)
Last I heard, Google discontinued publishing device trees and driver binaries for Pixel devices with their recent changes to their stewardship of the AOSP [0]. Was it something definitive or are they merely delayed? If the practice is being discontinued, what would be the reason why? Doesn't publishing these artifacts create a business case for customer demand for the Pixel devices? Or is there some cost that outweighs the benefits? Is it maintainer overhead?

I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!

[0]: >>44259921

>>minima+0A
Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. A few OEMs publish more basic device trees for older Android versions. This was Pixels losing one of their advantages compared to non-Pixels but it was never one of our hardware requirements, which are listed at https://grapheneos.org/faq#future-devices. It isn't part of why Pixels are the only devices meeting our requirements. We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027.

GrapheneOS typically ports to new yearly Android releases in a couple days and tends to have it reach the Stable channel in under 2 weeks. We completed our initial port to Android 16 in a similar time period after the release on 2025-06-10. However, we then had to reimplement device support in a similar way to how we would support a non-Pixel device. Our initial production release based on Android 16 was published on June 30th. As usual, we had to spend around a week making a series of releases fixing regressions reported by users. It reached our Stable channel on July 8th.

Since our port to Android 16 took significantly longer than usual, we backported most of the Android 16 firmware, all of the kernel drivers and parts of the userspace device support to our now obsolete Android 15 QPR2 branch and did a few more releases based on Android 15 QPR2 where we were able to provide the full 2025-06-05 patch level which also turned out to be the full 2025-07-05 patch level due to no vulnerability fixes in the July 2025 Android Security Bulletin or Pixel Update Bulletin. This was an unusual approach and not generally a reasonable way of doing things. We were able to do it successfully.

It won't be nearly as much of an issue going forward since we dealt with building the new automation we needed. Our port to Android 16 QPR1, Android 16 QPR2, Android 16 QPR3, Android 17, etc. shouldn't be nearly as difficult and we should get back to our typical porting time for major releases.

>>strcat+RC
Quite a lot of detail on this comment, thanks for that!

But I'm still left a bit confused about the future devices GraphaneOS will support:

Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?

You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?

Thanks again!