(Well, the hard part is learning how to download all of the source code and learning how to use the Android build system, and then downloading a new system image onto the Android device; there is no technical restriction which prevents you from doing this.)
I developed the ext4 encryption specifically for Chrome and Android, and I was building my own Android images and putting it on putting it on a Nexus 9 device. This didn't require any kind of special privilege or encryption keys only available to Google employees. Neither did this:
https://thunk.org/android-xfstests
It's all open source, and you can certainly rebuild your kernel, make other changes to the firmware, and install it on your phone. No reverse engineering or hardware/firmware exploits necessary!
However, Google's approach is so uncommon, that it's basically the exception that proves the rule. The vast majority of device manufacturers don't do anything like this, and if you were to pick a phone at random, you would probably expect to encounter some sort of issue flashing it. That's why we're still stuck with databases of "if you want to run a custom Android ROM on your phone / OpenWRT on your router / etc., pick from one of these known-good devices."
I say this almost preemptively, because I really don't think it should obscure your core point: open devices are increasingly the exception, not the norm.
1: https://chdk.fandom.com/wiki/CHDK 2: https://hackaday.com/2020/09/06/a-free-software-os-for-the-r...
Google takes licensing seriously (as both know you and I know :-).
No idea why we do the same for Android phones though. No GPLv3 in there :-).
Every device or platform since the IBM PC, including phones, tablets, non-x86 PCs, thermostats, wristwatches, routers, appliances, cars, etc. -- all of them have switched to the device-only-accepts-firmware-signed-by-the-manufacturer model where you can't put your own software on the vast majority of devices without a significant amount of reverse engineering and hardware/firmware exploit hunting.
Software can't eat the world if nobody wants to make hardware that can run arbitrary software. Then it's only "this one particular company's software can eat your thermostat for the two years that they feel like providing device support, then it's trash."
I think that hardware (or at least boot architecture) does matter. For all of UEFI's flaws, the secure boot model is actually pretty good. A device can come with a preloaded manufacturer key, and can be configured by default to only run manufacturer signed firmware. But once a user buys the device, they have the option of adding an additional key, either from another third party (i.e. like the key that RedHat and Ubuntu use to sign their kernels), or keys that you or your organization generate and manage yourselves. You can also remove the preloaded key, because as the owner of the device, you should be able to do whatever you want with it. If the manufacturer needs their application to only work if the secure boot settings haven't been altered (i.e. in a car, with safety/liability concerns), they can do that.
I would be a lot happier if we had a model like this for literally any other non-PC platform. Right now everybody rolls their own crappy implementation of signature checking with hard-coded manufacturer keys. It's really pretty awful.