> who essentially do all the work for Android already

They don't, that's the whole point. They do the bare minimum of booting up a barely-usable, heavily hacked downstream kernel, and call it a day (or rather, move to the next device release). "Proper" support is left to the community.

Look, I kind of agree with the sentiment, but I think your comment doesn't paint a very realistic picture of the situation. I'd estimate that there are above 3 orders of magnitude more people working on Android at the chip vendors than there are people working in the community. Which, these days, includes quite a lot of user space work, as well as the kernel.

Essentially, any phone vendors other than the big names expects to get a fully-working Android image with their chipset to ship with the phone. And Google also punted a bunch of lower-end userspace work off on the chip vendors as well. Chip Vendors don't just ship drivers in that market. Not if they expect to sell any chips.

Source: Worked at a chip vendor.

OK then, replace "kernel" in my previous comment with "kernel plus a bunch of lower-level userspace". If anything, this makes things worse not better. It means we're re-introducing the possibility of duplicated effort and gratuitous breaks of compatibility in that lower-level userspace, which is exactly what we were trying to get away from via AOSP.

This makes it more important rather than less to work on an AOSP alternative that's far more in line with existing Linux practices in the mainstream, non-embedded ecosystem. And let's face reality, the chip vendors aren't doing it.

Sure. But what happened in non-embedded was that a lot of the chip vendors were eventually persuaded to lend their support to the Linux ecosystem. If that doesn't happen in mobile, the community faces an uphill struggle.

The chip vendors came around because the community was standing behind the ecosystem, not for any other reason. We've been through this before.