And yes, they're not obligated to provide those binary blobs, but since they've been doing it for such a long while, not announcing it well in advance, like they do with the so many services they choose to discontinue, just adds to that list of things I dislike about them.
Yeah, yeah, it's a bit more work to publish those binaries and make sure they work. But they still kind of have to do that, for themselves. So I think it's fair to assume why they did it. Because they made a choice to take a small loss on the devices they would sell for the few GrapheneOS users, and cash in on the walled garden, data mining, ads serving, yada yada, whatever brings the extra money after the initial phone sale.
This is such a strange position. "I rely on an undocumented behavior, and I'm upset that things changed".
If you're a software engineer, you know not to depend on these kind of things, and there's no way to expect the library / framework author to reason about how people are using it.
What if someone else came up and said I'm using Pixel as a doorstop, and now that Pixel has a camera bump, it doesnt work anymore - I hate the company. Strange indeed.
Their support of Pixels with AOSP has been well documented! This has always been one of their selling points, as a sort of reference device. I've exclusively bought Pixel phones in recent years and this is one of the primary reasons.
Of course Google never made any guarantees, and a rug pull was always possible, but it's absolutely still disappointing and well worth commenting upon.
AOSP recipes themselves list reference devices and they could have updated this with their announcement in March if they didn't want external developers procuring these things as bricks for their gardens. GrapheneOS is just a community of a AOSP derivative there are any number of AOSP derived things people may have been doing with these devices.