alt Hacker NewsThis comes up every time, I just don't understand the argument. You can fork AOSP when that happens. It will still be far less work than bootstrapping a viable open source alternative from scratch. Also maintaining a forked AOSP would be less work than getting the Linux desktop stack on the same level as AOSP.
Given that Android apps target old API levels, it would also stay compatible for years and nothing would hold you from implementing APIs from the docs.
To be honest, I don't think AOSP will fully close up, since Google probably fears the regulatory pressure and the fallout from vendors. The larger risk is Play Integrity, but that applies equally to other Linux systems if you want to tap into the large Android app ecosystem. But the solution for that is not technical, the EU and other regulatory bodies should make forbid it in its current form due to anti-competitiveness.
> This comes up every time, I just don't understand the argument. You can fork AOSP when that happens
Hacking on the Linux stack is several orders of magnitude more practical than AOSP though. AOSP's build system is massively unwieldy for individual contributors to work on. You can't easily work on any of the system components without dedicating >100 GiB of storage for a build, for example. Everything is scattered across hundreds of repositories tied together with a bespoke repository management tool.
This all works for a company equipped with entire build infrastructure teams, not for a grassroots project trying to keep up maintenance with (at best) limited funding. It's why Nura (fka postmarketOS) is a thing whereas the various AOSP forks barely ever modify the core experience.