I’m sorry but I have no idea what that sentence means
As far as I am aware, on the Sony devices I use and build for regularly, relocking the bootloader is not possible. So I’ve never had an issue with running devices with an unlocked bootloader: it’s the price you pay for running a custom ROM.
I only own the sunfish, so that I have a device that is officially supported by LineageOS and can be used to check that any problems in the ROMs I build are nit due to building for a non-supported device.
If you think that the sunfish ROM should be re-lockable, perhaps you could point me at some documentation on how to do it, and on why it is possible / desirable for this device when it is not possible for others?
The iodé team shows how it is done with their ROM for the Google Pixel 4 (flame) and Pixel 5 (refin).
CalyxOS, DivestOS and GrapheneOS have been building custom ROMs with AVB key for the Google Pixel 4a (sunfish) for years and prove that the bootloader can be locked again.
Security and privacy easy
this is pretty easy to support/enable, you just have to integrate the following into your builds
builds must be -user, not -userdebug
in DivestOS-Build repo:
signing keys can be generated correctly using Scripts/Generate_Signing_Keys.sh $device
Scripts/Common/Copy_Keys.sh is used to copy verity keys into kernels
processRelease() in Scripts/Common/Functions.sh is used to sign releases
devices can have verified boot re-enabled using enableVerity() in Scripts/Common/Functions.sh
you need to sed -i 's/^\treturn VERITY_STATE_DISABLE;//' drivers/md/dm-android-verity.c on all kernels, to restore verified boot that LineageOS disabled
you’ll need to apply Patches/*/android_build/0002-OTA_Keys.patch to android_build repo to correctly add keys to the recovery
update_device_info.sh in DivestOS-Website repo has device bootloader information in the format: unlock method, bootloader
I always make user-debug builds, as it’s the only way to have a working backup / restore solution fir use when installing Android upgrades or migrating to a new device.
I have edited my original post to make clear that this build
Verified Boot Locked bootloader leads to additional device security.
Bootloader locking is the process of enabling the bootloader security that makes secure boot possible. Verified Boot strives to ensure all executed code comes from a trusted source, rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions including system an vendor partitions. During device boot up, each stage verifies the integrity and authenticity of the next stage before handing over execution.
In addition to ensuring that devices are running a safe version of Android, Verified Boot checks for the correct version of Android with rollback protection. Rollback protection helps to prevent a possible exploit from becoming persistent by ensuring devices only update to newer versions of Android.
In addition to verifying the OS, Verified Boot also allows Android devices to communicate their state of integrity to the user.
A re-locked bootloader isn’t a handicap to backup really important, irretrievable personal data externally.
According to the information you posted from Divest OS, bootloader can only be relocked on user builds. user builds do not allow rooted debugging, so the Android Backup and Restore tools I linked to will not work. These are the only backup / restore solution I know that actually works. So I make and use user-debug builds so that I can back them up. And bootloader cannot be relocked in user-debug builds
Each of us does what we think is right and important.
My smartphones with re-locked bootloader veried boot, from Google Pixel models, to Oneplus 5 + 6 and Xiaomi Mi A2, running CalyxOS, GrapheneOS and iodéOS, run like clockwork. And that’s important to me.
I have discovered the followinf problem:
F-Droid will offer an update to microG Services Core, but installing the update will fail with the error
Error installing microG Services Core
Error -7: A previously installed package of the same name has a differnet signature than the new package (and the old package's data was not removed)
I have created this issue about this, but in the meantime the workaround is to choose Ignore this update from the ‘3 dots’ menu.
Just wondering (as I’m new to custom ROMs) how would updates work on this vs. an official build for LineageOS or Iodé? Would there be any updates or would the initial installation be everything?
Two big differences between this build and official LineageOS or Lineage for microG builds (or IodéOS official builds for other devices):
There won’t be “over the air” (OTA) updates like there would be for official LineageOS, Lineage for microG, IodéOS (or /e/OS) builds. You would have to download the updates when they become available, and flash them manually. Normally you can do what is called a “dirty flash” (i.e. installing the update without wiping your existing data), so that you don’t lose your installed apps and user data.
Updates won’t get made automatically. LineageOS and Lineage for microG make regular builds - nightly or weekly. At the moment IodéOS seem to be releasing new versions / updates roughly every month. For my custom ROM builds, I usually make a new build whenever it seems appropriate to do so. For IodéOS, I would expect to make new builds shortly after IodéOS make a new version (e.g. 3.5) available. How long after will depend on how busy I am, how many other things I have on my plate, and what the weather is like, when that happens*. Also, I can’t guarantee how long I will go on making builds of IodéOS (or any of the other builds I make). But I don’t currently have any plans to stop.
If regular, guaranteed updates, or OTA updates rather than manual installation, are important to you, then I would suggest that you stick with official builds, either from Lineage for microG (who, like IodéOS, are now releasing Android 12 (S)/LOS 19.10 builds) or /e/OS (who, are still only on Android 11 (R)/LOS 18.10 builds for this device, and who generally seem to lag a bit behind LOS when it comes to bug fixes and security patches).
But there’s nothing stopping you from giving this ROM a try. If you don’t get on with it, or if updates don’t come as frequently as you would like, you can always intsall Lineage for microG instead. If you have access to a Linux computer, you can use this backup tool to migrate (most of) your installed apps and user data to the new installation.
* I build custom ROMs for fun, as a hobby, in my spare time. At the moment, I spend quite a lot of time on it, because the weather is dreadful, so my other time-consuming pastimes are on hold When the weather improves, I’ll be spending less time building ROMs
