Using AOSP is very viable. It's very different using AOSP to target a device intended to be used by you for development vs. using Pixels. You have *3 years* of security updates for each of the major releases and you get device support code from your vendor(s) in a usable state.
Conversation
So when a release like Android 11 comes out, it's a non-event and you can migrate at your own pace. Even without being a partner with early access, it's not much of a major issue. There's nothing to hack together or reverse engineer. AOSP isn't the problem at all.
1
Also, thanks to Treble, you can keep shipping AOSP updates including the major version upgrades without necessarily having support for them from the vendor(s). You can move to Android 11 while using Android 10 vendor support. Better to have it overhauled, but it's not mandatory.
1
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.
2
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
Also, the fact that Pixels move to the quarterly maintenance releases and major versions as soon as they're publicly released. There are nearly no other devices where that's the case. You don't go through that experience with pretty much any other device.
An Android 10 kernel and vendor image support Android 11 on top of them. An Android 11 kernel or vendor image does not support using it with Android 10 on top of it. So, Pixels immediately moving to the new major version is why there's a sudden crisis / time pressure applied.