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.
Conversation
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.
1
3
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.
Since they stop publishing factory images and device support code for the previous major release. With your own device, you control your own destiny in that regard. AOSP supports each major release for 3 years and your vendor updates won't require a new major release of Android.
1
2
Without your own device, simply targeting ANYTHING other than a Pixel, since the OEM takes longer to migrate you have a lot more time to port your changes and get your fork of AOSP ready. Treble also allows moving to a new major release without device support code being updated.
1
1
Show replies
Can you name an example of this?
Maintaining deterministic and blob free AOSP for Google devices needs hundreds of person hours. Changes too fast and Google dgaf.
If there is a device with true first party AOSP support keeping up with Google upstream that would be amazing.
1
I have seen many vendors take stabs at this but they end up abandoning support once they have a new gen device leaving the community with a massive support nursing that can't even begin to keep up (see lineageos)