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
Conversation
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.
2
3
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
Pixels make this hard, since they move immediately, right when the new OS you need to port your code to becomes publicly available, and they immediately drop support for the previous major release. Treble means AOSP is backwards compatible with device support code, but new device
1
2
support code isn't backwards compatible with an old version of AOSP so we can't simply continue having GrapheneOS based on Android 10 while shipping Android 11 device support code. Forced to migrate rapidly which is extremely difficult. All of this is caused by targeting Pixels.
1
2
Our long-term goal is to be targeting custom hardware in collaboration with organizations like Calyx, where hardware is produced to suit the needs of multiple projects. Would no longer have these issues regardless of how much SoC vendor code is open + can take time to migrate.
+ even if SoC vendor code isn't open, at least we'd still get to audit, modify and build most of it internally including a lot of the SoC firmware. Maybe there would be an SoC vendor with decent security and open source device support code at that point - right now, not really.
1
1
I mean Librem5 and Pinephone type hardware with the only chailnge being the addition of a proper TPM stack for secure boot stuff would still mean a very small number of blobs and worlds easier to maintain AOSP for than anything that exists today.
2
2
Show replies
If plans are seriously going in that direction I would happily put my time and $ on the table.
The current path of spending endless hours hacking around constantly changing undocumented binary blob hardware vendors like Google... that seems like a dead end. They will never care.
1
Until then I suggest we encourage parallel paths like Pinephone and Librem5 and push for future iterations that can support proper secure booted AOSP as well as other green field OS experiments.
1
1
Show replies