More and more major Android phone manufacturers are guarding bootloader unlocks behind excessive verification steps for "safety" reasons, as if anyone who would think of doing bootloader unlocks/rooting would not know of such risks already (Xiaomi is a big offender on this point). OnePlus is still one of the few remaining phone brands that allow for users to bootloader-unlock their phones, but even so their tooling to reset the phone to the original state (e.g. the thing formerly known as MSMDownloadTool) seems to now be locked behind Oppo's gated service stuff requiring accounts to do so. And the few other brands that still allow for easy "no-questions-asked" bootloader unlocks, are relatively less mass-produced ones, like Pixel and Nothing (by other OnePlus co-founder Carl Pei). Bootloader unlocks allows for custom ROMs, which by themselves allow for users to extend the service life of their sometimes rather new devices (e.g. 3-4 years old) which no longer receive security patches simply by the OEMs being lazy (or simply for their own incentives).
Google allowing for bootloader unlocks for Pixel phones, doesn't mean Google is off the hook here either. They're pushing Play Integrity as a "secure API" that allows for devs to verify that a device is secure enough. But by itself the newer Play Integrity API, as far as I know, checks for the bootloader unlock status, and checks the *latest security update version*. The very instant you unlock your bootloader, lots of things start to break for your daily life (banking apps no longer work, some auth applications don't work, etc). They say this is for the name of "protection for the user", but when the user knows full-well of their risks, there should be a supported path that doesn’t treat them as automatically untrustworthy forever, or at least make it clear for the developer side that using the default integrity checks of theirs, would guard against applications being used even on perfectly functional phones on custom ROMs.
They could've done
- A system-level "informed risk acceptance" mechanism that a user can enable intentionally (with friction if you want), instead of forcing a degraded phone experience.
- Or a more nuanced integrity model where developers can choose "high risk, allow with warnings / step-up auth" instead of "hard fail".
- Or, if Google insists on integrity signals, provide an escape hatch for advanced users that’s based on actual security properties (hardware-backed keys, secure enclave attestations, step-up verification), not simply "stock ROM + locked bootloader or you’re out."
A lot of this is currently less for protecting users and more like normalizing a world where you "pay every few years to keep the privilege of compatibility". A world where repairability and longevity loses to vendor control.
Rant over.