Bootloader Primer
Bootloader basics
The first software the phone starts into is (aptly named) the bootloader. As a security feature, this software verifies that the OS on your phone is safe to use and then starts it (it “loads” it).
To do that, it scans several important partitions to check that everything is as it should be. A partition is a chunk of your memory that’s reserved to special software.
system and boot are two exemples of system partitions and are updated when Android or your favorite ROM are updated. vendor is another type of partition. All your data (photos, downloaded apps..) is in userdata, a third type of partition.
The content of each partition is called partition image (when downloaded, it’s something *.img).
As a factory setting, the booloader is locked. That means that a new/untouched phone has a verified and unchanged image for each partition. That is to say, no part of the software was modified and it can’t be modified (unless from an update).
The bootloader has a security feature that cryptographically checks that the system image on the phone is authentic (from the original manufacturer, i.e. Fairphone Android OS). Unlocking the bootloader makes it bypass those checks and then the system can boot any valid OS (with which the phone will still work).
To install new OS (e.g. LineageOS, /e/OS, Ubuntu Touch…), one first needs to unlock the bootloader. Unlocking the bootloader implies several steps. Fairphone provides the steps to do it in the Manage the bootloader support pages.
first steps with fastboot
The interface with which you interact with the bootloader is called dic:fastboot (dedicated post to installing).
Try $ fastboot oem device-info, which tells you a bit about the current state of the device, including about the bootloader. In an otherwise untouched system, it would answer, among other things :
(bootloader) Device unlocked: false
(bootloader) Device critical unlocked: false
It can be useful to check the flag called get_unlock_ability.
A flag returns two possible values : 0 if it’s false/off/“answer is no”, and 1 if it’s true/on/“answer is yes” (flag is “raised”).
If the bootloader can be unlocked, then the command $ fastboot flashing get_unlock_ability should return 1.
This does not mean that the bootloader is unlocked yet.
The Manage the bootloader page provides more steps regarding unlocking the bootloader.
A/B slots
This section is a stub.
The A/B system is a new-ish system to manage Over-The-Air (OTA) updates. Some partitions have two sets, A and B, called slots, that are virtually duplicates of the same partition.
The system is running on one slot and the OTA update is applied to the other slot. At the end of the update, the phone reboots and the slot is switched.
That way if an update fails, one slot is always working.
Let’s say you are on slot A. An OTA update arrives and you update successfully. At the reboot, you boot into slot B with the new version. Slot A is still on the old version, untouched.
If anything happens to the system at that point and slot B is compromised or broken, the phone should be able to boot into slot A.
All this is seamless, it should be happening without user input or knowledge.
Now the A/B system is transitioning (or has already: it’s a requirement “for devices lauching with Android 11 and higher”, i.e. FP4) to a virtual A/B system where only the differences between A and B are kept, and not two complete copies as it was earlier. As far as I understand, it still works the same as two slots.