You and me both. With android 11 and beyond working to move as much of AOSP as possible into proprietary modules, the ship on being able to have free and fully user controllable privacy respecting android devices is sailing.
Conversation
AOSP doesn't have blobs itself. Devices have a mix of open and closed source components as part of their Treble implementation. AOSP sits on top of a Treble implementation. There are open source Treble implementations The typical Qualcomm-derived one has many proprietary bits.
1
1
6
Treble has made things much easier if you only want to change AOSP rather than doing device-specific work. We haven't been able to take advantage of the main benefits for GrapheneOS since we have to do device-specific hardening work. It hasn't gotten any harder in recent years.
1
5
Making production builds of AOSP for Nexus and Pixel devices isn't nearly as easy as it should be due to Google not dedicating the necessary resources to including the open source Qualcomm device support code in AOSP along with build integration for closed source libraries, etc.
1
5
The issue is that Qualcomm makes the sources available to their partners, so Google's internal tree builds these things from source. They haven't dedicated resources to providing as much of that as possible publicly with build integration for firmware/libraries that are blobs.
1
3
It's an issue with Nexus and Pixel devices. It's not an issue if you have your own device with direct vendor support or if you're using community-developed or AOSP-provided device support code. The issue is that Nexus and Pixel devices don't have proper public AOSP support.
1
3
Nexus obviously isn't relevant anymore, the issues were the same with those. I really don't see how any of it got harder to handle. It was way harder to deal with the Nexus 9 and then the Nexus 5X and 6P than recent devices. Nexus 9 introduced the vendor image, and they stopped
1
4
releasing device support packages split out into individual files with a build system putting them in the right place and wiring up dependencies. Instead, they started expecting people to use the unaltered vendor image, even though a substantial portion of it is open source.
1
3
So, the issue started with the Nexus 9 is that AOSP provides most of what you need to build the vendor image, but they don't go out of their way to publish all the open source Qualcomm repositories as part of AOSP and then offer integration for the closed source portions.
1
3
They can't simply publish the full vendor trees they include in the AOSP tree alongside the AOSP device repositories, because they build components from source that are not open source. A lot is open source, but not all. They'd need to dedicate resources to it, and they haven't.
If you aren't building AOSP for Nexus or Pixel phones, none of this is relevant and you aren't really impacted in any way by the way they handle this. If you're building AOSP for anything else you wouldn't have a use for Google's internal Pixel vendor source tree.
1
3
There are vendors making it a lot easier to build AOSP for their devices than Pixels. It's a misconception that Pixels are the easiest devices to support. Also, the devices moving immediately to the new major release on day one makes it harder, not easier, since you have to move.
2
3
Show replies