A thought … how feasible, I don’t know, but a thought nonetheless …
The Fairphone 3 is an A/B device. It holds two OS installations at a time, after an update the old version is still there. User data is shared (not doubled).
The cool thing is … users should be able to switch the OS slots and thus boot the old version (by disrupting the boot process into the new version a few times intentionally, if more convenient methods are unavailable with a locked bootloader?).
The “uncool” thing is … rollback protection. With obvious good intentions, this mechanism breaks the possibility to simply fall back to the old OS version in case of obvious trouble after updating, because if the old version is on an older security patch level (which it usually is), a factory reset will be needed to boot the old version, user data as well as user-installed Apps and their data will be deleted.
This kind of bugs me, conceptionally.
The result of this protection is that a quick and practical fix for users in case of serious issues after an update is disabled for a gain many affected users would legitimately consider much less important, if given a choice.
What if OS updates could be split into updates which do substantial changes while keeping the same security patch level date as before … and later updates which only raise the security patch level date?
This way, after a feature update the possibility to fall back to the old OS version in case of obvious trouble would be left intact, because rollback protection wouldn’t kick in?
And a later update ideally just raising the patch level date wouldn’t break stuff and could be started by users once they are sure they don’t need to fall back?
I don’t know whether the deed of only raising the date is left to the discretion of the OS vendor, or if raising the date would have to be bundled with actual security patches. In the latter case, leaving 1 patch undone until the date-raising update should do the trick.
Wouldn’t this be possible?