Unofficial build for Google Pixel 4a (sunfish)

I have created an unofficial build of IodéOS for Google Pixel 4a (sunfish)

It is available on AndroidFileHost here

I installed it using Lineage OS 19.1 recovery image downloaded from here flashed as described here

I flashed the recovery and installed the build following the LineageOS instructions here

Note that this build

I’m very happy to happy to know if anyone finds it useful, and to receive any feedback


@petefoth, well done!

Since no avb_custom_key-sunfish.bin is ready, the bootloader can not be locked again. This feature would be the i-dot for your unofficial iodéOS ROM.

1 Like

I’m sorry but I have no idea what that sentence means :slight_smile:

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?


1 Like

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/ $device
    • Scripts/Common/ is used to copy verity keys into kernels
    • processRelease() in Scripts/Common/ is used to sign releases
    • devices can have verified boot re-enabled using enableVerity() in Scripts/Common/
    • 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
  • in DivestOS-Website repo has device bootloader information in the format: unlock method, bootloader

(c) @SkewedZeppelin 8/2021

1 Like

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

  • does not support re-locking the bootloader
  • is a user-debug build
1 Like

Absolutely right
Thats the only thing on user build that totally annoys me, that i cannot enable adb root to creste backups

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

1 Like

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.

Is this build fully de-googled?

Like the official IodéOS builds, this is built from

The only change I made was to comment out this line in one of the device makefiles to allow the LineageOS code to compile.

Apart from that, I have not added or removed any code in my build. So it is as “de-googled” as the official IodéOS builds - see here


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):

  1. 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.

  2. 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 :slight_smile: When the weather improves, I’ll be spending less time building ROMs


Yes, thats the best backup tool
but unfortunately not usable in normal iodé builds

1 Like

Where you comming from? England? :wink:


really, i thought the weather in england never can improve? :wink:

A new unofficial Iodé 4.0 build is now available at AndroidFileHost

I have clean flashed this, and everything seems to work OK. Dirty flash over the previous 3.4 build may work, but I have not tested it.

Note that this build

Have fun!

1 Like

Here’s a new build.

It fixes the signing problems documented in this issue and this post

Clean flash, and dirty flash over the previous version both seem to work OK