> but 3rd party ROMs will not.

Google are also making that harder, at least for the Pixel line by no longer publishing the device tree as part of AOSP.

I know Fairphone do publish a buildable tree - though it's not yet available for their latest device - does anyone else?

Also, you cannot unlock most phone's bootloaders nowadays, so you cannot even try them.

Google only directly controls the Pixel line because of antitrust action from the EU.

Originally, device makers who used Android themselves were contractually prohibited from manufacturing devices for any company that forked Android, for instance.

Google can force OEMs implement non-unlockable secure boot.

And (present tense) forces OEMs to not ship with utilities that let users access their own data

Fairphone wanted to give users full access on the Fairphone 2, but were contractually disallowed if they wanted to also ship the Android Market, Google Maps, etc., which users can't otherwise install themselves so it was essential to pre-install for a normal user experience. That's why they made two OSes for that phone: a googleful one and a free OS based on AOSP that you can install if you don't want Google (https://code.fairphone.com/projects/fairphone-2/fairphone-op...). Nowadays they let the /e/ Foundation do that work with e/OS. They're supportive of it but apparently don't have the internal manpower to continue making and supporting an extra distribution

What is non-unlockable secure boot?

State of the art SoC with silicon baked private keys laser fused for production configuration

"Silicon baked private keys" are really vague buzzwords. That's pretty much standard and it can be implemented in a variety of ways.

Not sure why you're calling this non-unlockable. Everything is unlockable with enough money.

You're not going to be decapping and recapping SoCs at scale... Lots of eFuse implementations are just writable ROMs with erasing lines disabled, and people aren't taking out particle accelerators to wipe them.

Whatever silly OTP implementation is involved is 99.9% irrelevant to unlocking a phone, and OTP for root-of-trust has been in use in phones for 15+ years anyway.

Maybe we use some hardware-level trick to get to some protected firmware initially to reverse engineer it, but almost universally it's what reads the state of the fuses (or something after it) that actually gets exploited. That's changing, too, but in general very slowly and at at the pace of hardware manufacturers learning how to make software (aka, glacial with a few notable exceptions).