Could this brick the phone due to Anti-Rollback?

Installation Help
1

Hello folks.

I have a stock Pixel 9 Pro (caiman) with Android 16, being its last security update on March 5 2026 (didn’t upgrade it in a few months, compilation version CP1A.260305.018). As both installers for IodeOS (for linux and Win) didn’t pass the “downloading configuration”, I tried to perform the manual update and after downloading the image I noticed that the baseband and bootloader versions on the current device are newer than the ones the latest IodeOS 7.6 provides. In particular:

baseband_device: g5400c-251201-260127-B-14784805

baseband_iode: g5400c-250908-251105-b-14386369

bootloader_device: ripcurrentpro-16.4-14791556

bootloader_iode: ripcurrentpro-16.4-14097580

So my question was towards the Anti-Rollback: could performing the manual install with IodeOS 7.6 might trigger the Anti-Rollback protection and brick the phone?

For reference, I tried searching in the community and on Google’s documentation, but it seems that only the P6/8/10 series have a comment about them, and nothing is mentioned for the P7/9 series, so I can’t tell for the P9 when was the last minimum threshold. Has anyone successfully installed IodeOS that would place older baseband/bootloader versions into the device? Or should I NOT proceed with the flashing?

Thanks in advance.

2

I used our graphical installer (on Linux) to install 7.5 on caiman in the past month, no issues were encountered. So I am curious about that part of your issue (another person reported something about the installer not responding after “Downloading Configuration” that I will need to look up again, or maybe that was you on our email suppport? :slight_smile: )

But to your question, as I understand only the Vendor Security Patch Level is applicable in triggering ARB or not. And ARB is only triggered when re-locking the bootloader, which I would guess you would like to do, but I am just noting it here for others.

But if you are uncertain, it may also be helpful for you to keep it unlocked on first install, then confirm all working, make sure “Allow OEM Unlocking” is still enabled in the running system, and then boot to fastboot and lock it afterward with fastboot flashing lock (it will reset your userdata so after that do the work to put all your data and configuration on the phone).

To your main question on why the baseband and bootloader versions are not matched, I think this is largely because of the delay to LineageOS applying some things (?) but I am only speculating and not exactly sure. Again, as Vendor Security Patch Level should be up-to-date (esp. with March 2026) I think you should be fine to install and relock again directly (but a stepped approach to not lock immediately as noted above may give you more confidence).

3

Thank you @rik for the prompt response.

graphical installer (on Linux) […] or maybe that was you on our email suppport?

That wasn’t me. In case it helps to debug, on Linux (Arch) I got the following error when I moved from the 3rd to the 4th page of the installer (“Preparing the installation”) and then it got stuck:

[ERROR:flutter/runtime/dart_vm_initializer.cc(40)] Unhandled Exception: type 'String' is not a subtype of type 'int?' in type cast
#0      new Device.fromJson (package:installer/config_provider.dart:127)
#1      new Configuration.fromJson (package:installer/config_provider.dart:51)
#2      Config.fetch (package:installer/config_provider.dart:184)
<asynchronous suspension>

Tried later with Win11 and it failed on the same page, but I don’t have a debugging output to share sadly.

ARB & bootloader lock

The question originally came because I saw a comment for another degoogled ROM on which even with the bootloader unlocked, a manual OTA bricked the phone due to the Anti-Rollback time-frame. In that case, it was with a P8, which Google informed about the May update. However, for the P9 I can’t know for sure if there was a similar point in time where this could be triggered.

To put some light in my concern: if I flashed IodeOS into slot A (active), and during the reboot that one got rejected due to the older bootloader/baseband compared to the current one (can’t tell where the minimum version is nowadays), and the slot B (inactive, which should be older) is also having an older bootloader not accepted by the current minimum, the device might get bricked.

Funny thing: during this rabbit hole I found out that my inactive slot was in fact non-bootable and with a faulty state for the fastboot, so this might have happened.

largely because of the delay to LineageOS applying some things

That’s interesting. Wondering if those could be fetched from a different project, as I unzipped the latest release for another ROM, and they have the same version as I currently have for the bootloader/baseband.

Will explore a bit more about it and then try it on one of the slots, now that they are mirrored.

Thanks again!

4

An error was found in the graphical installer config that is downloaded at runtime and was preventing it from running. That has now been fixed, meaning you could also re-try the graphical installer.

About ARB concerns, using https://flash.android.com I have commonly gone backwards from stock A16 to stock A15 just fine, etc. I am a bit confused about the reports this has not been possible. So I would use stock flashing to put it on a version with a VSPL (Vendor Security Patch Level) older than what iodéOS includes. Then proceed to install iodéOS (now with the working Graphical Installer).

Here is the commit history for 7.6: Commits · v7.6 · os / public / devices / google / device_google_caimito · GitLab, which indicate it may be at the 2026-02 vendor security patch level. I would recommend just putting on the December 2025 version to be double-safe: Android Flash Tool (you need a Chromium-based browser to flash directly), then you are fully cleared to proceed with iodéOS install.

2 Likes
5

I ended up taking a different path and forgot to update it in here after my prev response.

For anyone interested, what I did:

  1. I first manually went to the damaged slot B and reconstructed the partitions and then flash each one of those with the same stock ROM I had on slot A. Same applied for the bootloader and radios.
  2. Tested both slots to see if they worked as they should. There were mirrored.
  3. Downloaded the IodeOS 7.6 zip file and instead of using the script, I went into slot A and first tried to install just the older bootloader that comes with the ROM. In the worst case scenario, either the flash process will have a check that would prevent me to put an older version there due to ARB, or after rebooting the bootloader in slot A it would fail and start looping, which would default into switching to slot B, which was a mirror of the stock slot A and that it worked just fine.
  4. As it rebooted without problem, I moved forward to the old radios. Same principle. Worked.
  5. Then manually formatted/erased the metadata, pushed the custom key, and updated slot A with the ROM, which also deleted the slot B ROM. Bootloader in B is still the stock one, so I had that card.
  6. Rebooted into the ROM in A and it worked.
  7. Locked the bootloader after testing the ROM.

I am a bit confused about the reports this has not been possible

It was on the P8 after the May update that changed its ARB. For reference, these were the comments I saw. For the P9 I couldn’t find any mention of if the ARB has or has not been changed after the lineup was released, so that’s why I checked in here.

An error was found in the graphical installer config that is downloaded at runtime and was preventing it from running. That has now been fixed, meaning you could also re-try the graphical installer.

Awesome! I gave it a dry run now and it seems to be working on my end with the same installer version – at least it downloads the configuration and allows me to move forward into the next page. Thank you for tackling it. Will use it in the future.

Thanks again for the response @rik

1 Like