I've worked with vendors using AOSP on their own hardware, and it's a far different experience. They don't have to deal with any of the nonsense. They get a source tree from Qualcomm to build vendor, the boot chain, etc. and the tooling for signing firmware + setting up fuses.
Conversation
If a vendors want, they can take that and ship a device that others can use with their own OS, while still having all the standard hardware/firmware security features. This is the part Google does. What they don't do is releasing usable device support code for use with AOSP.
1
There are vendors doing a better job with releasing usable AOSP device support code for their devices. If you have the impression that Pixels are anything close to the best at that, it's very wrong. Pixels just have the best hardware/firmware privacy and security properties.
1
It would be so much easier to support a device from one of the vendors publishing fully usable device support code. The time it takes them to switch over to new major releases is also a huge help to downstream variants of the public AOSP. Also, not adopting quarterly releases.
1
You have said this but I have not seen this in any devices I have looked at (granted a couple years ago).
Can you point me to specific devices that are going to be less hellish to target than Pixels today for Android 11?
1
1
Due to Treble, you don't need them to support Android 11 to use AOSP 11 with their device support code.
Most of the pain we have with Pixels is due to us not using Treble, because we want to build the vendor image, while from their perspective it's abstracted hardware details.
1
The way that Treble works is that you build a system image from AOSP and can run that on any device. Building boot and vendor is separate, and you can update them independently. For Pixels, Google hasn't tried to publish code for building / assembling the vendor image.
2
Yeah treble seems great on paper but... Point me at hardware to try it on.
If I can get latest vanilla AOSP on any device without weeks of hacking then suddenly my view of the future if android starts to shift substantially.
1
BTW, the way android-prepare-vendor does things for Pixels is obsolete and based on the hassle we had with the Nexus 9, 5X and 6P. It's not how it would be approached now. You would start by just using their vendor image and would then transition to building it + listing files.
2
Step one being building all the obvious components from AOSP and then listing out everything that's missing, and then it's done. Optionally going further by bringing in assorted CAF repositories, etc. The way android-prepare-vendor deals with it is super over-engineered now.