At most you have people applying tiny patches on top of AOSP, but 100% of the code in the underlying project is still Google-approved, and none of the alternatives have control over that.

You are making an orthogonal point. Yes, Google maintains AOSP. No, that does not mean that AOSP OSes that are not in Google's Android program (calling it that to avoid semantics games) have to adopt this change. If you want to hear it from the experts: https://grapheneos.social/@GrapheneOS/116103732687045013

▲

paxys 4 hours ago | parent [-]

Unless these different Android flavors all have the resources to indefinitely rewrite AOSP and remove all Google code they don't agree with - no, they pretty much have to adopt the changes (see the earlier Chromium example). And if they do somehow manage this after a point all the patching basically becomes a fork, which is exactly what I started the conversation with.

	▲	microtonal 3 hours ago \| parent [-]
		I see your point, but it all hinges on when you consider the changes to be a patch set and when a fork. I don't think there is a very clear definition, except I don't think most of these projects would call themselves AOSP forks. At any rate, this particular Google anti-feature does not require a large patch (or maybe none at all).