6 ms·

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].

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]: https://news.ycombinator.com/item?id=44259921 https://news.ycombinator.com/item?id=44259921

NewJazz 1y ago
I heard unsubstantiated rumors that it was somehow antitrust-related. If they are selling off their device business (again), then it makes sense that the device drivers would not be part of AOSP...
- strcat 1y ago
  > If they are selling off their device business Android and Chrome are potentially going to be split from Google: https://www.nytimes.com/2024/11/20/technology/google-search-chrome-doj.html https://www.nytimes.com/2024/11/20/technology/google-search-... (https://archive.ph/egRL4 https://archive.ph/egRL4) Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.
strcat 1y ago
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 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.
- ulrikrasmussen 1y ago
  I am so excited about the thought of a GrapheneOS native phone!
- minimalist 1y ago
  I suppose this means that supporting future Pixel devices will be more difficult? If someone has the ear of anyone at Google, especially someone who works with Android, please share this cause with them!
  - poisonborz 1y ago
    The comment above was describing in great detail how this is not the case and after some initial effort should prove no difference at all.
  - fifteen1506 1y ago
    Generic power-user here: I am going to guess without the backing of Google going forcefully open-source, "niche" hardware such as Google's Tensor will lose their attractiveness. However one must note also that for now not even Snapdragon fulfills GOS requirements. If/when that changes, Snapdragon devices may have more open-source community momentum than Google's Tensor. Plus all the economy of scale, etc.. In terms of security, Microtek is even more far behind Snapdragon. Again, not an Android dev here, take the text above with a grain of salt, YMMV, etc..
- 71bw 1y ago
  Is it now possible to build a custom release of graphene for any of my non-Pixel devices or will that, again, bring graphene ninjas to my abode?
- notachatbot123 1y ago
  > We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027. Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference https://news.ycombinator.com/item?id=44586723 https://news.ycombinator.com/item?id=44586723)
ysnp 1y ago
It may be permanent and I think this was the official indirect response: "AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0] Emphasis on independent of any particular hardware. Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]). [0]: https://www.androidauthority.com/google-not-killing-aosp-3566882/ https://www.androidauthority.com/google-not-killing-aosp-356... [1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-will-push-google-to-sell-off-chrome-to-break-search-monopoly https://www.bloomberg.com/news/articles/2024-11-18/doj-will-...

NewJazz 1y ago

I heard unsubstantiated rumors that it was somehow antitrust-related. If they are selling off their device business (again), then it makes sense that the device drivers would not be part of AOSP...

strcat 1y ago
> If they are selling off their device business Android and Chrome are potentially going to be split from Google: https://www.nytimes.com/2024/11/20/technology/google-search-chrome-doj.html https://www.nytimes.com/2024/11/20/technology/google-search-... (https://archive.ph/egRL4 https://archive.ph/egRL4) Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.

strcat 1y ago

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 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.

ulrikrasmussen 1y ago
I am so excited about the thought of a GrapheneOS native phone!
minimalist 1y ago
I suppose this means that supporting future Pixel devices will be more difficult? If someone has the ear of anyone at Google, especially someone who works with Android, please share this cause with them!
- poisonborz 1y ago
  The comment above was describing in great detail how this is not the case and after some initial effort should prove no difference at all.
- fifteen1506 1y ago
  Generic power-user here: I am going to guess without the backing of Google going forcefully open-source, "niche" hardware such as Google's Tensor will lose their attractiveness. However one must note also that for now not even Snapdragon fulfills GOS requirements. If/when that changes, Snapdragon devices may have more open-source community momentum than Google's Tensor. Plus all the economy of scale, etc.. In terms of security, Microtek is even more far behind Snapdragon. Again, not an Android dev here, take the text above with a grain of salt, YMMV, etc..
71bw 1y ago
Is it now possible to build a custom release of graphene for any of my non-Pixel devices or will that, again, bring graphene ninjas to my abode?
notachatbot123 1y ago
> We're working with a major Android OEM to change that though, hopefully for 2026 or at least 2027. Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference https://news.ycombinator.com/item?id=44586723 https://news.ycombinator.com/item?id=44586723)

ysnp 1y ago

It may be permanent and I think this was the official indirect response: "AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0] Emphasis on independent of any particular hardware. Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]). [0]: https://www.androidauthority.com/google-not-killing-aosp-3566882/ https://www.androidauthority.com/google-not-killing-aosp-356... [1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-will-push-google-to-sell-off-chrome-to-break-search-monopoly https://www.bloomberg.com/news/articles/2024-11-18/doj-will-...