How To Guide April 2, 2024 AP1A.240405.002 Global - Root Pixel 6 Pro [Raven]

[radekmazur]

I updated the flash-all.bat to reflect the changes mentioned above but have this error:
error: failed to load image-bluejay.....zip

What is that?

Ok, I fixed it.

 

[roirraW "edor" ehT]

Just FYI , those who haven't come across this issue: I was updating to 13 by means of adb sideload because google decided to push Android 12 again (Germany/EU), mistake on their end. Sideload failed at "verify update package", just sat there doing nothing for an hour before i killed it. I found this neat info on this thread that was a straight forward fix. using the only USB 2.0 port on my machine it worked right away. Not even 5 minutes. Thread author might point this out at the start of the thread? pretty general info though. Fastboot and ADB both appear to be working on USB-C to C, just not sideload. Dunno were this info could be posted best to save people hours of searching.

That's good information to share, and I've seen others share that same information independently, but just FYI everyone, that information definitely isn't true for everyone.

I use the USB-C (3.2 Gen 1 and Gen 2) ports on my desktop computer to flash my Pixel 6 Pro and my Samsung Galaxy Tab S8 Ultra 100% fine.

I have even done it through a USB-C port on the desktop, with a long cable going to a USB hub, where I then use a USB-A cable. I have done it all those ways without issue. I did have to change USB-C cables yesterday, but still used a USB-C port.

 

[roirraW "edor" ehT]

Ok, I fixed it.

What fixed it? Different USB cable or port?

 

[Sneakyghost]

That's good information to share, and I've seen others share that same information independently, but just FYI everyone, that information definitely isn't true for everyone.

I use the USB-C (3.2 Gen 1 and Gen 2) ports on my desktop computer to flash my Pixel 6 Pro and my Samsung Galaxy Tab S8 Ultra 100% fine.

I have even done it through a USB-C port on the desktop, with a long cable going to a USB hub, where I then use a USB-A cable. I have done it all those ways without issue. I did have to change USB-C cables yesterday, but still used a USB-C port.

There is a high probability it is not actually USB-C to C. It might be the active cables many use now (those with integrated chip), it might be the platform, and lastly, you also said "flash" but did you mean sideload or fastboot? Because i verified both ADB and Fastboot on that connection first and most functions returned no errors. Only when i went into recovery and there into sideload mode, that connection was bad.

I could do some more digging like I used to back in my HTC days, grab my top tier notebook and run the sideloading again there to see if it still applies, swap cables from active to passive, etc, but on the one hand i really dont have the nerves for that anymore and on the other hand it should suffice for readers to know they should consider the connection when things fail.

 

[radekmazur]

What fixed it? Different USB cable or port?

I forgot to extract the contents of image file (.zip) into the ADB folder, so ADB had trouble locating the needed files. Once I extracted the files into the ADB folder, it all started working.

 

[Lughnasadh]

Let's just hope that ARB is only tied to downgrading to the A12 bootloader and not other parts of the OS as well.

Google's statement wasn't exactly clearcut in my mind. I think a bad result could potentially lead to a more than undesirable outcome, if you know what I mean. Of course, I could just be overly paranoid

Eh, the more I read about it the more I think it is just bootloader version related

Btw...

https://twitter.com/i/web/status/1559537708959154177

 

[roirraW "edor" ehT]

There is a high probability it is not actually USB-C to C. It might be the active cables many use now (those with integrated chip), it might be the platform, and lastly, you also said "flash" but did you mean sideload or fastboot? Because i verified both ADB and Fastboot on that connection first and most functions returned no errors. Only when i went into recovery and there into sideload mode, that connection was bad.

None of my USB-C (or USB-A -> USB-C) cables are active cables. They're just normal, inexpensive but quality basic cables. Or do you mean yours?

I never sideload, but that would indeed be strange if actually flashing a full factory image would work 100% but sideloading wouldn't. I wouldn't accept basic ADB and Fastboot commands as being enough indication that the connection definitely works for flashing a full factory image, either.

I could do some more digging like I used to back in my HTC days, grab my top tier notebook and run the sideloading again there to see if it still applies, swap cables from active to passive, etc, but on the one hand i really dont have the nerves for that anymore and on the other hand it should suffice for readers to know they should consider the connection when things fail.

That's okay. I accept that the same solution isn't necessary for everyone, I just wanted to put it out there that what caused the issue for you and for some people might not necessarily be a problem for others. And absolutely, the particular hardware involved can be the issue. A long time ago, I used to run into more finicky flashing issues where using particular ports mattered. My latest self-built desktop from a year and three-quarters ago has had much better luck flashing no matter what USB port I use.

 

[roirraW "edor" ehT]

I forgot to extract the contents of image file (.zip) into the ADB folder, so ADB had trouble locating the needed files. Once I extracted the files into the ADB folder, it all started working.

Awesome! Glad it was something simple. Happens to all of us from time to time.

 

[Homeboy76]

@Lughnasadh @roirraW "edor" ehT

What if you edited the flash-all.bat file this way (see bold information below). Would it flash the new factory image to boot slots?

If yes, that would eliminate the need to add --skip-reboot or the need to switch slots.

...PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-bramble-b5-0.5-8633619.img --slot-all
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-bramble-g7250-00208-220623-b-8759277.img --slot-all
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot update image-bramble-tp1a.220624.014.zip... --slot-all

 

[roirraW "edor" ehT]

@Lughnasadh @roirraW "edor" ehT

What if you edited the flash-all.bat file this way (see bold information below). Would it flash the new factory image to boot slots?

If yes, that would eliminate the need to add --skip-reboot or the need to switch slots.

• @Echo off
  :: Copyright 2012 The Android Open Source Project
  ::
  :: Licensed under the Apache License, Version 2.0 (the "License");
  :: you may not use this file except in compliance with the License.
  :: You may obtain a copy of the License at
  ::
  :: http://www.apache.org/licenses/LICENSE-2.0
  ::
  :: Unless required by applicable law or agreed to in writing, software
  :: distributed under the License is distributed on an "AS IS" BASIS,
  :: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  :: See the License for the specific language governing permissions and
  :: limitations under the License.
  
  PATH=%PATH%;"%SYSTEMROOT%\System32"
  fastboot flash bootloader bootloader-bramble-b5-0.5-8633619.img --slot-all
  fastboot reboot-bootloader
  ping -n 5 127.0.0.1 >nul
  fastboot flash radio radio-bramble-g7250-00208-220623-b-8759277.img --slot-all
  fastboot reboot-bootloader
  ping -n 5 127.0.0.1 >nul
  fastboot update image-bramble-tp1a.220624.014.zip --slot-all
  
  echo Press any key to exit...
  pause >nul
  exit

Ah, good point. I forgot about that, but that does seem familiar now. My answer is: probably.

 

[Zilla0617]

Have an issue that I can't solve. Ever since I upgraded to A13 my device will not sleep, 100% awake. Never had this issue and I'm trying to avoid performing a factory reset.

So I'm seeing system server and Android hardware sensors causing high cpu when I check in terminal. The hardware sensor specifically is Android hardware sensors @2.1-service.multihal. I tried restarting, reflashing with -w, changing kernels. Nothing works

EDIT: After performing a factory reset, still encountered the issue. Tap, Tap ended up being the cause of the high drain. Once I forced stop the app, my CPU went down. Ultimately, deleted the app. Phone enters deep sleep now

 

[Lughnasadh]

@Lughnasadh @roirraW "edor" ehT

What if you edited the flash-all.bat file this way (see bold information below). Would it flash the new factory image to boot slots?

If yes, that would eliminate the need to add --skip-reboot or the need to switch slots.

• @Echo off
  :: Copyright 2012 The Android Open Source Project
  ::
  :: Licensed under the Apache License, Version 2.0 (the "License");
  :: you may not use this file except in compliance with the License.
  :: You may obtain a copy of the License at
  ::
  :: http://www.apache.org/licenses/LICENSE-2.0
  ::
  :: Unless required by applicable law or agreed to in writing, software
  :: distributed under the License is distributed on an "AS IS" BASIS,
  :: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  :: See the License for the specific language governing permissions and
  :: limitations under the License.
  
  PATH=%PATH%;"%SYSTEMROOT%\System32"
  fastboot flash bootloader bootloader-bramble-b5-0.5-8633619.img --slot-all
  fastboot reboot-bootloader
  ping -n 5 127.0.0.1 >nul
  fastboot flash radio radio-bramble-g7250-00208-220623-b-8759277.img --slot-all
  fastboot reboot-bootloader
  ping -n 5 127.0.0.1 >nul
  fastboot update image-bramble-tp1a.220624.014.zip --slot-all
  
  echo Press any key to exit...
  pause >nul
  exit

I know that works for flashing boot images to both slots, but I couldn't say definitively it would work with flashing the whole factory image. I look forward to you trying and telling us how it went

 

[Homeboy76]

I know that works for flashing boot images to both slots, but I couldn't say definitively it would work with flashing the whole factory image. I look forward to you trying and telling us how it went

@Lughnasadh @roirraW "edor" ehT

The factory image is large.

So, maybe these edits of the flash-all.bat file are better:

...fastboot update image-bramble-tp1a.220624.014.zip...
fastboot--skip-reboot
fastboot --set-active=a (If you're on slot b)
fastboot --set-active=b (If you're on slot a)
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
- Verify bootloader slot change
- At the command prompt (on your computer), type flash-all to flash the factory image to the other slot.

Or

Flash the factory image to your phone.
After it reboots
- set you phone up
- Reboot
- fastboot adb reboot bootloader
- Change slot
fastboot --set-active=a (If you're on slot b)
fastboot --set-active=b (If you're on slot a)
Flash the factory image to the other slot by typing flash-all at the command prompt.

 

[Lughnasadh]

I thought you may be feeling lucky today

 

[Lughnasadh]

The factory image is large.

But seriously, I'm not sure it's even a good idea to do that. What if something goes wrong during flashing and you have both slots end up being corrupted? May be harder to get out of. Not impossible of course since there may be other methods to recover. For me, it's always nice that you know what of your slots is still good (e.g. when you get into a bootloop and it eventually switches to the other slot to boot). It's really just a time and effort saver to do both slots at once but not sure the rewards would outweigh the possible pitfalls, at least for me.

Just my 2 cents...

 

[whatsisnametake2]

so what's the definitive situation re going back to 12 after you've updated to 13?

 

[roirraW "edor" ehT]

so what's the definitive situation re going back to 12 after you've updated to 13?

I don't think there is a definitive situation, as no one has expressed wanting to go back.

The only thing I know for sure is that if you're still on Android 12, you can definitely flash the Android 13 Stable bootloader ONLY, and I was still able to boot Android 12. Doesn't mean squat, really.

Downgrading without wiping is always a very risky thing: After upgrading to a newer version (even a regular monthly update), system app data may have been updated as well (it's very likely at least some system apps have). Downgrading to an earlier version of Android won't downgrade the app data, so suddenly you're running an older version of Android with app data meant for a newer version. At best, you'll have weird issues. At worst, your phone won't boot. I don't have the time to set my phone up from scratch if I can help it, so I won't be testing downgrading (with or without Android 12's bootloader) any time.

If you have the time and test this process, please let us know how it works out. It's "possible" that you can flash everything from Android 12 but the bootloader itself, and it might still work. Even if so, this doesn't mean that a further bootloader change in Android 13 after more updates will remain compatible with Android 12.

I haven't liked doing mix or match partition images on my device in the last six years, however.

 

[whatsisnametake2]

I don't think there is a definitive situation, as no one has expressed wanting to go back.

The only thing I know for sure is that if you're still on Android 12, you can definitely flash the Android 13 Stable bootloader ONLY, and I was still able to boot Android 12. Doesn't mean squat, really.

Downgrading without wiping is always a very risky thing: After upgrading to a newer version (even a regular monthly update), system app data may have been updated as well (it's very likely at least some system apps have). Downgrading to an earlier version of Android won't downgrade the app data, so suddenly you're running an older version of Android with app data meant for a newer version. At best, you'll have weird issues. At worst, your phone won't boot. I don't have the time to set my phone up from scratch if I can help it, so I won't be testing downgrading (with or without Android 12's bootloader) any time.

If you have the time and test this process, please let us know how it works out. It's "possible" that you can flash everything from Android 12 but the bootloader itself, and it might still work. Even if so, this doesn't mean that a further bootloader change in Android 13 after more updates will remain compatible with Android 12.

I haven't liked doing mix or match partition images on my device in the last six years, however.

fair enough. what is the technical reason you can't flash a 12 bootloader after a 13 bootloader? is it not just flashing data into a certain area of the phones memory? overwriting any existing data? outside my knowledge zone that one.

 

[roirraW "edor" ehT]

fair enough. what is the technical reason you can't flash a 12 bootloader after a 13 bootloader? is it not just flashing data into a certain area of the phones memory? overwriting any existing data? outside my knowledge zone that one.

This warning at this page:

Warning: The Android 13 update for Pixel 6, Pixel 6 Pro, and the Pixel 6a contains a bootloader update that increments the anti-roll back version. After flashing an Android 13 build on these devices you will not be able to flash older Android 12 builds.

and:

PSA: You can't downgrade from Android 13 on Google's latest Pixel phones

You can't downgrade from Android 13 on Google's latest Pixel phones, so keep that in mind if you hop between builds a lot.

www.xda-developers.com

August 15, 2022 2:10pm Adam Conway

PSA: You can’t downgrade from Android 13 on Google’s latest Pixel phones​

Android 13 was just released for Google’s Pixel smartphones, and you can install it right away by going to your phone’s settings and checking for an update. However, if you have a Google Pixel 6, Google Pixel 6 Pro, or a Google Pixel 6a, then be warned: trying to roll back to Android 12 after updating will trip your phone’s anti-rollback protection. This means that the update to Android 13 is essentially permanent.
We spotted the warning on the Android 13 factory images page, where it says the following:

“The Android 13 update for Pixel 6, Pixel 6 Pro, and the Pixel 6a contains a bootloader update that increments the anti-roll back version. After flashing an Android 13 build on these devices you will not be able to flash older Android 12 builds.”

This anti-rollback protection is not unlike mechanisms that some companies, such as Xiaomi, have employed in the past. For context, Xiaomi implemented anti-rollback protection by surprise on the Redmi Note 5 through a software update. When users went to downgrade they then bricked their smartphones, as they did not know they needed to be careful.

If you use your phone normally and don’t flash between different system images, then you have nothing to worry about. However, if you’re the kind of person that likes to jump between different versions, maybe hold off for a little bit. It’s not clear if you’ll actually brick your phone by downgrading after updating to Android 13, but it’s better to be safe than sorry and to wait and see what happens. You also don’t need to worry about it if you’re using an older Google Pixel phone.
As for why this only affects the latest Pixel phones, it’s not clear. However, all three of these devices are powered by Google Tensor, meaning that it might be something unique to Tensor, and might be why Google is implementing it. Anti-rollback protection is implemented through Verified Boot, and will ensure that a security vulnerability cannot be used by a malicious actor to install an older version of the Android system.


Source: Android factory images page

I don't know anything technical about it beyond the information given in those two places.

 

[whatsisnametake2]

This warning at this page:


and:

PSA: You can't downgrade from Android 13 on Google's latest Pixel phones

You can't downgrade from Android 13 on Google's latest Pixel phones, so keep that in mind if you hop between builds a lot.

www.xda-developers.com

I don't know anything technical about it beyond the information given in those two places.

thanks for the info. I don't understand why google is doing this tho. they are very liberal when it comes to flashing and rooting. why implement an anti roll back boot loader? what's wrong with going back to 12 if you have some random issue on 13?