[Google Pixel 6 Pro] Namelesswonder:
@V0latyle @roirraW "edor" ehT

Thinking about it and what has happened so far to a couple people there may be a way to test if the Android 12 bootloader is capable of allowing Android 13 to increment the counter, and then also a test to see if the older bootloader images implement the counter, and whether this means we can downgrade the Android 13 bootloader.

Previously a user updated to Android 13 and booted into it. Then wanted to test the claim Google made that you can't downgrade the bootloader back to Android 12. They found that they could switch the slot back over to the one with Android 12, however when attempting to boot into the bootloader on that slot they would just get punted back to the slot with Android 13.

We also know that they couldn't interact with the slot that had the Android 12 bootloader.

So the test to see if this case of the Android 12 bootloader still functioning after Android 13 was booted is dependent on an older possibly non-ARB aware bootloader is for this:

Someone to be on Android 12 still.

For them to flash the April image in it's entirety to their phone, all partitions and all slots to be the April release. Wipe would necessary.

Update to Android 13 using any of the methods that leave Android 12 on one of the slots, through a sideload/OTA or flash of only one slot.

Boot into Android 13 successfully on the slot that contains Android 13.

Go back into the bootloader, switch to the slot with Android 12, and try to fastboot reboot bootloader into it.

This shouldn't result in any bricks because these are the steps that @Bunnehbunn took, except they didn't upgrade from the April release, they updated from a later Android 12 release.

If they can boot into the older bootloader then that means that this older bootloader does not check for the counter. Additional testing with additional "untainted" phones would be required to check the May, June, 1st July, 2nd July bootloaders. What would this mean?

The April Android 12 bootloader does not implement the ARB counter.

Thus having this specific or potentially earlier bootloader is not leaving up the chance for a brick.

The later Android 12 bootloaders implement checking the ARB rollback counter.

Thus having these later bootloaders is leaving up the chance for a brick to occur

Additional testing would then be required to see if you can use this older bootloader to then downgrade the bootloader on the Android 13 slot back to an older version.

If this can be done then that means there is a way to downgrade from the Android 13 bootloader, however it would require this specially crafted scenario of circumstances: April (or potentially other) bootloader on one slot, Android 13 bootloader on the other slot.

If they however can't boot into the older bootloader then that means either of two things:

The Android 13 bootloader is checking if the other slot is allowed to be switched to and booted.

This shouldn't be the case because it allows you to freely switch to the other slot.

The April Android 12 bootloader has an ARB counter check to see if it is allowed to be used.

If it is the latter, then that proves definitively that on the April Android 12 bootloader is does not have the required interface to allow the counter to be incremented, only the ability to check the counter.​

​

This means @enderdzz never had their ARB counter incremented because their older bootloader did not let Android 13 increment the counter.​

​

This would then also shed light on the circumstance of the bricks:​

The Android 13 slot becomes unbootable through some method of corruption or bad flash.

The Android 12 bootloader can't be loaded because it fails the ARB counter check, so tries to load the other slot.

The Android 13 slot can't be booted because it is marked unbootable, so tries to load the other slot.

Repeat

This would also explain why that GrapheneOS tester had a completely dead and unresponsive to USB phone, it's constantly trying to boot what it believes is a bootable slot, so it can't drop into EDL mode. We know the Pixel 6 can enter EDL mode, people have seen it shown up in the device manager when they've managed to bork both slots. We don't have the EDL tools to use EDL mode though.​

Hopefully this extremely long post can get us all into agreement on what is happening, what can be done, and what might happen if someone tries to do something to experiment. Google is not giving us the crisp details, so we have to find them.