Hey everybody,
sorry for the new thread, but I feel like the risk of getting my fresh device bricked is too high if I'm not taking reassuring measures - especially considering the kinda confusing instructions posted here. And yes, I read them all.
I'm getting my P6Pro Replacement Device tomorrow. Since I think that it will still be on A12 I need to upgrade; since I used my previous 6 Pro rooted I wanna root the replacement device too.
What would be the best way to achieve this? Should I just take the normal update route, then unlock the bootloader, change the slot and use flash-all there to flash the factory image to the inactive slot? Or is unlocking the bootloader at that moment too risky? I'm well versed with the factory image update process due to me updating that way on a monthly basis with root, so that would be the most familiar way.
What I dont get in most of the instructions here, is that I'd still be booting up A13 after upgrading with one partition still being on A12. Isnt that the thing that I want to avoid, since a failed boot up with A13 would result in the A12 partition being loaded and thus a bricked phone.
@roirraW "edor" ehT described in his post with regarding this topic here https://forum.xda-developers.com/t/...tral-repository.4352027/page-52#post-87291469
how you include a line that prevents the system from booting up after flashing the first partition and then describes in the step for step instruction how he boots up the system after flashing the first partition where would i insert that line in the flash-all script? After the mentioned line and create a new line or really directly behind it?
Thanks all for clearing that up!!
xflowy said:
Hey everybody,
sorry for the new thread, but I feel like the risk of getting my fresh device bricked is too high if I'm not taking reassuring measures - especially considering the kinda confusing instructions posted here. And yes, I read them all.
I'm getting my P6Pro Replacement Device tomorrow. Since I think that it will still be on A12 I need to upgrade; since I used my previous 6 Pro rooted I wanna root the replacement device too.
What would be the best way to achieve this? Should I just take the normal update route, then unlock the bootloader, change the slot and use flash-all there to flash the factory image to the inactive slot? Or is unlocking the bootloader at that moment too risky? I'm well versed with the factory image update process due to me updating that way on a monthly basis with root, so that would be the most familiar way.
Click to expand...
Click to collapse
Hello!
If I were doing it fresh from a brand new Pixel 6 Pro, I would unlock the bootloader first thing. This will wipe your phone, but it's brand new out of the box and doesn't hurt anything.
Then from running Android I would:
Code:
adb reboot bootloader
then
Code:
fastboot flash bootloader --slot all bootloader-raven-slider-1.2-8739948.img
Once that's done, I would flash-all.bat from the Android 13 factory image zip. In this particular case, I would even leave the "-w" in the flash-all.bat, but it's up to you. Just don't forget that the -w is still in there, in case there's some reason for you to use the same flash-all.bat yet again, but don't want to wipe later.
xflowy said:
What I dont get in most of the instructions here, is that I'd still be booting up A13 after upgrading with one partition still being on A12. Isnt that the thing that I want to avoid, since a failed boot up with A13 would result in the A12 partition being loaded and thus a bricked phone.
Click to expand...
Click to collapse
Not partition, one slot. As long as you do the:
Code:
fastboot flash bootloader --slot all bootloader-raven-slider-1.2-8739948.img
xflowy said:
@roirraW "edor" ehT described in his post with regarding this topic here https://forum.xda-developers.com/t/...tral-repository.4352027/page-52#post-87291469
how you include a line that prevents the system from booting up after flashing the first partition and then describes in the step for step instruction how he boots up the system after flashing the first partition where would i insert that line in the flash-all script? After the mentioned line and create a new line or really directly behind it?
Thanks all for clearing that up!!
Click to expand...
Click to collapse
That post of mine you linked to is already ancient news (relatively speaking with all the posts we've had about Android 13) and although correct, it's not 100% necessary to fully flash Android 13 to both slots, it's only important to flash the Android 13 bootloader to both slots.
You'll be fine. You're welcome!
xflowy said:
Isnt that the thing that I want to avoid, since a failed boot up with A13 would result in the A12 partition being loaded and thus a bricked phone.
Click to expand...
Click to collapse
The new ARB fuse only gets lit (ARB counter started), so to speak, after you boot into A13. So if you updated to A13 but the update failed and you weren't able to boot into A13 you would be safe because you didn't actually boot into A13 yet.
But as @roirraW "edor" ehT , the best way to alleviate any worries is to flash the A13 bootloader to both slots before anything.
And make REAL sure...if you use a patched boot that you made previously...make sure it was made from AFTER you took the A13 update. Flashing to both slots and then rooting with the wrong patched boot image will make u headbutt your desk until ur half unconscious...don't ask me how I know...I'll just deny.
Guys, just to be clear again.. I did like you proposed and flashed the A13 Bootloader to both slots, then flashed the A13 update to the active slot (a) and am now on 13.
So now, when I'm about to update to the september sec. update, I just go the normaly way via updating with a factory image that I used to to? Or should I flash the september update to both slots now to be sure?
@roirraW "edor" ehT @Lughnasadh thank you again! <3
xflowy said:
Guys, just to be clear again.. I did like you proposed and flashed the A13 Bootloader to both slots, then flashed the A13 update to the active slot (a) and am now on 13.
So now, when I'm about to update to the september sec. update, I just go the normaly way via updating with a factory image that I used to to? Or should I flash the september update to both slots now to be sure?
@roirraW "edor" ehT @Lughnasadh thank you again! <3
Click to expand...
Click to collapse
If you flashed the A13 bootloader to both slots, and verified that they were flashed to both slots, then yeah, you can update to the September build the way you normally do. If via flashing the factory image, you'll still have A12 on the other slot (b) but that's ok because you have the A13 bootloader on that slot to protect you.
So basically, with the A13 bootloader on both slots you can carry on normally and not have to worry about the ARB/eFuse fiasco.
Related
So I might have gotten a nice stroke of luck here. Got a Pixel XL from Verizon with no intentions to do any modifying of any kind. I took the OTA update to 7.1.1. A few weeks later, I finally dove into the forums to see what kinda development we got going for this phone. I read that the bootloader is forever locked. Since buying the phone, I had tons of freezes, crashes, and reboots. I sent the phone in to Verizon and got my replacement with 7.1! I unlocked the bootloader and I couldn't hold true to my initial plans of not modifying it. Currently I have a Verizon Pixel XL, bootloader is unlocked, twrp, franco r6 kernel, root. On build NMF26O. What is the best/quickest method for updating with these monthly security patches and such?
https://forum.xda-developers.com/pixel-xl/how-to/guide-how-to-unlock-root-flash-pixel-xl-t3507886
Step 9
joooe said:
https://forum.xda-developers.com/pixel-xl/how-to/guide-how-to-unlock-root-flash-pixel-xl-t3507886
Step 9
Click to expand...
Click to collapse
Either I'm going crazy or just plain dumb, but there's only 8 steps when I go to that link
jdpro22 said:
Either I'm going crazy or just plain dumb, but there's only 8 steps when I go to that link
Click to expand...
Click to collapse
You are right LOL. There is no Step 9 :laugh:
I myself am not clear yet, but I think you need to flash stock recovery and kernel and then you could take the OTA update and install it. That will be the easiest. But I always like to do it clean, so I download the OTA and then sideload it via ADB. Obviously I take a backup before and then restore it.
But just make sure that there is a way to restore stock recovery, I am not clear about that part, stock boot.img is easy to find and flash, I don't know whether that restores the stock recovery too or not.
Start at step 4 here: https://forum.xda-developers.com/pixel-xl/how-to/info-how-restored-to-stock-soft-t3494478
Just remember to delete "-w" from flash-all.bat so your data is not wiped!
I have a Verizon Pixel XL with unlocked bootloader, TWRP, and root on NHG47K. I have been updating it via sideloading the OTAs since I got the phone. I've seen on the forums that a lot of people flash the full factory image. I wanted to know what the difference was between sideloading the OTA vs flashing the full factory image?
There is not too much difference,
OTA is changing only what has been changed, size varies with 100 MB to 600 MB of more. But if you had some problems with unchanged partitions they may not fixed.
Factory image flashing has bigger size (latest is 1.8 GB), wiping your data by default (manually editing for non wipe is possible), mainly for fresh start even without wiping data.
Thanks for the info. Couple more questions:
1. Does sideloading just the OTA, flip the active slot?
2. Is there a way to check if the April OTA updated the bootloader as well. I'm guessing the May OTA does update the bootloader since applying it has broken TWRP and root for people.
savi0 said:
Thanks for the info. Couple more questions:
1. Does sideloading just the OTA, flip the active slot?
2. Is there a way to check if the April OTA updated the bootloader as well. I'm guessing the May OTA does update the bootloader since applying it has broken TWRP and root for people.
Click to expand...
Click to collapse
Hello,
1 - OTA will install on the other slot.
2 - International April version has the same bootloader as March and earlier versions. There is an updated bootloader for Verizon, not the one that breaks Root/TWRP by the way. The May OTA does brake Root/TWRP.
Cheers...
5.1 said:
Hello,
1 - OTA will install on the other slot.
2 - International April version has the same bootloader as March and earlier versions. There is an updated bootloader for Verizon, not the one that breaks Root/TWRP by the way. The May OTA does brake Root/TWRP.
Cheers...
Click to expand...
Click to collapse
To clarify your meaning... The May Verizon OTA does or does not break root?
sliding_billy said:
To clarify your meaning... The May Verizon OTA does or does not break root?
Click to expand...
Click to collapse
Hello,
Every May releases break Root. It's a general security patch for Pixel devices (as far as I understand).
Cheers...
sliding_billy said:
To clarify your meaning... The May Verizon OTA does or does not break root?
Click to expand...
Click to collapse
Applying the OTA or flashing a full factory image does "break" root and TWRP in the sense that you have to reflash TWRP and apply root again. Apparently the May factory image/OTA is applying a new bootloader which is not allowing the re-application of TWRP and root after flashing. Chainfire made a post detailing that it was due to the new May bootloader detecting an unsigned image, ie TWRP, and then not allowing it to boot.
Here is the link to that post: https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
savi0 said:
Applying the OTA or flashing a full factory image does "break" root and TWRP in the sense that you have to reflash TWRP and apply root again.
Click to expand...
Click to collapse
Hello,
If you try to reinstall Root or TWRP after May OTA I think you are going to have a bad surprise. It's up to you...
savi0 said:
Apparently the May factory image/OTA is applying a new bootloader which is not allowing the re-application of TWRP and root after flashing. Chainfire made a post detailing that it was due to the new May bootloader detecting an unsigned image, ie TWRP, and then not allowing it to boot.
Here is the link to that post: https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
Click to expand...
Click to collapse
First you say you have to reapply TWRP and Root and now you say it won't allow it... You shouldn't reinstall either TWRP or Root on May bootloader for the moment.
If you want those, flash the April bootloader as stated in other threads talking about the issue...
Cheers...
5.1 said:
First you say you have to reapply TWRP and Root and now you say it won't allow it... You shouldn't reinstall either TWRP or Root on May bootloader for the moment.
If you want those, flash the April bootloader as stated in other threads talking about the issue...
Cheers...
Click to expand...
Click to collapse
Sorry, I should have clarified that you are only able to apply TWRP and root to images and bootloaders that were released before the May updates.
You are absolutely right in that that I should not be installing TWRP or Root on the May bootloader because it'll result in bootloops.
savi0 said:
Sorry, I should have clarified that you are only able to apply TWRP and root to images and bootloaders that were released before the May updates.
You are absolutely right in that that I should not be installing TWRP or Root on the May bootloader because it'll result in bootloops.
Click to expand...
Click to collapse
Hey,
As a workaround, you can flash April bootloader. It's not a big deal and works fine anyway.
Cheers...
5.1 said:
Hello,
Every May releases break Root. It's a general security patch for Pixel devices (as far as I understand).
Cheers...
Click to expand...
Click to collapse
That's what I assumed you meant (that the new BL was in all May builds), but your working sounded like maybe it was left out of the Verizon OTA build. I'm just waiting patiently for a TWRP/SU build that doesn't need me to mismatch the BL. It wasn't like there was any functional reason to upgrade in May.
sliding_billy said:
That's what I assumed you meant (that the new BL was in all May builds), but your working sounded like maybe it was left out of the Verizon OTA build. I'm just waiting patiently for a TWRP/SU build that doesn't need me to mismatch the BL. It wasn't like there was any functional reason to upgrade in May.
Click to expand...
Click to collapse
Yeah. A few posts above yours @savi0 pointed to a Chainfire posts relating the issue. You can also check the last posts from EX Kernel. flar2 posted a link to the latest security bulletin...
Normally, we won't have to wait too long to get back TWRP/Root.
Cheers...
sliding_billy said:
I'm just waiting patiently for a TWRP/SU build that doesn't need me to mismatch the BL. It wasn't like there was any functional reason to upgrade in May.
Click to expand...
Click to collapse
Although I have the Automatic system update option shut off, in the past my Pixel has used cellular data while remaining on the prior version after the update notification appears. I think the phone wasted about 1 GB the last time I didn't take an OTA update. That essentially means I can not take the update and possibly cause the phone to waste cellular data, shut off cellular data to avoid the usage while remaining on the prior version, or take the update. Actually I have seen a fourth option linked below, but that keeps my phone constantly awake and doesn't allow deep sleep, so I never tried the alteration long enough to see if it would avoid cellular data usage if the change was made before the OTA notification.
https://www.androidexplained.com/pixel-hide-ota-notification/
alluringreality said:
Although I have the Automatic system update option shut off, in the past my Pixel has used cellular data while remaining on the prior version after the update notification appears. I think the phone wasted about 1 GB the last time I didn't take an OTA update. That essentially means I can not take the update and possibly cause the phone to waste cellular data, shut off cellular data to avoid the usage while remaining on the prior version, or take the update. Actually I have seen a fourth option linked below, but that keeps my phone constantly awake and doesn't allow deep sleep, so I never tried the alteration long enough to see if it would avoid cellular data usage if the change was made before the OTA notification.
https://www.androidexplained.com/pixel-hide-ota-notification/
Click to expand...
Click to collapse
Hello,
I don't understand what you mean when you say:
alluringreality said:
That essentially means I can not take the update and possibly cause the phone to waste cellular data, shut off cellular data to avoid the usage while remaining on the prior version, or take the update
Click to expand...
Click to collapse
If you have issues, just sideload the latest OTA from Google here:
https://developers.google.com/android/ota
Instructions are available on this page.
Good luck...
alluringreality said:
Although I have the Automatic system update option shut off, in the past my Pixel has used cellular data while remaining on the prior version after the update notification appears. I think the phone wasted about 1 GB the last time I didn't take an OTA update. That essentially means I can not take the update and possibly cause the phone to waste cellular data, shut off cellular data to avoid the usage while remaining on the prior version, or take the update. Actually I have seen a fourth option linked below, but that keeps my phone constantly awake and doesn't allow deep sleep, so I never tried the alteration long enough to see if it would avoid cellular data usage if the change was made before the OTA notification.
https://www.androidexplained.com/pixel-hide-ota-notification/
Click to expand...
Click to collapse
I have been concerned about the system using data while waiting to update the phone, but I do not see that happening. I have automatic update turned off in dev settings as well as the google play services notification disables so as not to accidental click it. I see the update available if I look at the check for updates area in system, but it just is sitting at the download and install option there. I have checked my data use since the BL issue came about, and there is no data use besides normal.
Mainly I was just noting that not taking an update can potentially result in cellular data usage, in case anyone wasn't aware of the possible issue. The top items in my cellular data usage were the same as the images in the following thread when I avoided taking an OTA update.
https://forum.xda-developers.com/pixel-xl/help/android-os-sucking-mobile-data-t3597680/
savi0 said:
Sorry, I should have clarified that you are only able to apply TWRP and root to images and bootloaders that were released before the May updates.
You are absolutely right in that that I should not be installing TWRP or Root on the May bootloader because it'll result in bootloops.
Click to expand...
Click to collapse
Will the factory images (May or after) lacking the "Verizon" designation lock my Bootloader if flashed to a Verizon Pixel XL (That currently has Unlocked BL and TWRP)?
Sorry, but this is getting Hella confusing.
I'm going to update TWRP, then planning on flashing Factory Image 8.1.0 (OPM1.171019.021, Mar 2018) https://dl.google.com/dl/android/aosp/marlin-ota-nhg47q-73c108b9.zip
Do I need to worry about anything flashing this build?
Just trying to make sure I don't screw myself here, as I really NEED an unlocked Bootloader/ROOT... but I'm still running 7.1.1
Wish there was a forum for us with Verizon Pixels and Unlocked BL's...
PrettyPistol555 said:
Will the factory images (May or after) lacking the "Verizon" designation lock my Bootloader if flashed to a Verizon Pixel XL (That currently has Unlocked BL and TWRP)?
Sorry, but this is getting Hella confusing.
I'm going to update TWRP, then planning on flashing Factory Image 8.1.0 (OPM1.171019.021, Mar 2018) https://dl.google.com/dl/android/aosp/marlin-ota-nhg47q-73c108b9.zip
Do I need to worry about anything flashing this build?
Just trying to make sure I don't screw myself here, as I really NEED an unlocked Bootloader/ROOT... but I'm still running 7.1.1
Wish there was a forum for us with Verizon Pixels and Unlocked BL's...
Click to expand...
Click to collapse
If OEM unlocking is toggled and your bootloader is unlocked, just assume it is a google version. Flashing a factory image can't lock your bootloader.
shagbag913 said:
If OEM unlocking is toggled and your bootloader is unlocked, just assume it is a google version. Flashing a factory image can't lock your bootloader.
Click to expand...
Click to collapse
The "OEM unlocking" setting is greyed out. And underneath it says "bootloader is already unlocked" (slider is to the left).
That is what you mean by "toggled", correct?
Thanks for the reply! I appreciate it greatly.
PrettyPistol555 said:
The "OEM unlocking" setting is greyed out. And underneath it says "bootloader is already unlocked" (slider is to the left).
That is what you mean by "toggled", correct?
Thanks for the reply! I appreciate it greatly.
Click to expand...
Click to collapse
Yep.
Hi, bear with me, new at Motorola.
1. What are the slots A and B that we have inside TWRP? How to flash a ROM "inside" of both slots (as it is written in some sites)?
2. Can we upgrade an unlocked bootloader? I mean, phone starts at 7.1.1, we unlock, how to get the 8 (oreo) bootloader?
3. When we move to Android P, can we upgrade an unlocked bootloader to the next Android version?
4. Does rooting affect the OTAs? If so, what should we do to get them?
Thanks.
Technical said:
Hi, bear with me, new at Motorola.
1. What are the slots A and B that we have inside TWRP? How to flash a ROM "inside" of both slots (as it is written in some sites)?
2. Can we upgrade an unlocked bootloader? I mean, phone starts at 7.1.1, we unlock, how to get the 8 (oreo) bootloader?
3. When we move to Android P, can we upgrade an unlocked bootloader to the next Android version?
4. Does rooting affect the OTAs? If so, what should we do to get them?
Thanks.
Click to expand...
Click to collapse
1. Slots are only for seemless updates. Don't worry about anything else. Just flash once and reboot.
2. What? Just flash all to stock and you can update to Oreo. You need to OTA.
3. Same as above: through OTA.
4. Yes. Any modifications to any petition besides /data will cause OTA failures. Just use a "back to stock" method to get OTAs to work.
Technical said:
Hi, bear with me, new at Motorola.
1. What are the slots A and B that we have inside TWRP? How to flash a ROM "inside" of both slots (as it is written in some sites)?
2. Can we upgrade an unlocked bootloader? I mean, phone starts at 7.1.1, we unlock, how to get the 8 (oreo) bootloader?
3. When we move to Android P, can we upgrade an unlocked bootloader to the next Android version?
4. Does rooting affect the OTAs? If so, what should we do to get them?
Thanks.
Click to expand...
Click to collapse
1. The phone has dual slots for seamless updates, when you apply an update it goes to the other slot and is optimized and checked. Then it is booted, in theory one slot should always be a build behind, but that wasn't well thought out and has caused problems (good job moto). If you're thinking dual boot two roms, probably won't work as the data is shared by both slots and **** will ensure if two different roms try to play in the same sandbox. A lot of the zips around here flash to both slots to avoid that problem. In short, it shouldn't be tampered with unless you have a reason and know what you're doing.
2. An unlocked bootloader is unlocked until it is relocked (not advised) or unless moto ****'s itself and relocks itself. It has happened before. To upgrade to oero, as long as you are bone stock you can update OTA. If not, you can check this thread and download the appropriate files and do it manually.
3. In theory yes. If moto releases an update for us or if our devs build it.
4. If you root or flash a custom recovery, anything that modified the original checksums then OTAs will fail. If you want OTA then you need to be bone stock and you should check this thread.
---------- Post added at 12:10 AM ---------- Previous post was at 12:08 AM ----------
Uzephi said:
1. Slots are only for seemless updates. Don't worry about anything else. Just flash once and reboot.
2. What? Just flash all to stock and you can update to Oreo. You need to OTA.
3. Same as above: through OTA.
4. Yes. Any modifications to any petition besides /data will cause OTA failures. Just use a "back to stock" method to get OTAs to work.
Click to expand...
Click to collapse
lol you're always a step ahead.
Many thanks for the responses.
But I'm really afraid of bricking my phone. I've done this before with 2 Motorolas...
User had a Moto Z2 and just after entering it (Android 7.1.1), go flashing DU (https://plus.google.com/communities...5/stream/2a745c1e-aae6-4b50-93dd-14417258d7ce) followed by TWRP.zip according to the guide. Phone bricked and the user can't even go to flashboot mode.
How can we solve it? I mean, Asus has FlashTool to recover a dead messed phone (even partitioning it, even if you cannot boot or get into recovery, or flashboot). Samsung has ODIN. Can RSELite do the job? As far I could read, you need, at least, get into flashboot mode. If something messes, you're locked out. Is it right?
Anyway, as far I could read about, both slots must be at the same Android version, otherwise, phone does not boot.
How to "flash to both slots" one after another?
Hi guys.
I finally got the notification I was dreading: I can now do a system upgrade to Pie. But shall I?
Even disregarding the learning curve and the mixed comments, I'm weary that one or more of my apps would not be fully compatible yet and would give me trouble.
So my question is: if I decide to go back for any reason, can I do so by simply flashing an Oreo factory image and get to keep my data, or maybe by restoring an Oreo nand backup?
Or is it more complicated by that because of the rollback protection thingy I've been hearing about?
BreadedChicken said:
Hi guys.
I finally got the notification I was dreading: I can now do a system upgrade to Pie. But shall I?
Even disregarding the learning curve and the mixed comments, I'm weary that one or more of my apps would not be fully compatible yet and would give me trouble.
So my question is: if I decide to go back for any reason, can I do so by simply flashing an Oreo factory image and get to keep my data, or maybe by restoring an Oreo nand backup?
Or is it more complicated by that because of the rollback protection thingy I've been hearing about?
Click to expand...
Click to collapse
Interesting question that has two answers. There are those that say you can by clean fastbooting the factory image, and there are those that say you can't because of the bootloader and google's stupid roll back prevention. I've read about people rolling back before, but have never tried it personally. I suppose you could fastboot the last DP5 to get a taste of 9.0, then roll back to 8.1 if you don't like it. Your call my friend.
I have also never tried it but if it works it's likely not that easy because of the mentioned Bootloader Lock.
Either way my approach would be to find out if those apps that are important to you would work on pie by searching the Forums or play store comments.
Gesendet von meinem SHIELD Tablet K1 mit Tapatalk
Badger50 said:
Interesting question that has two answers. There are those that say you can by clean fastbooting the factory image, and there are those that say you can't because of the bootloader and google's stupid roll back prevention. I've read about people rolling back before, but have never tried it personally. I suppose you could fastboot the last DP5 to get a taste of 9.0, then roll back to 8.1 if you don't like it. Your call my friend.
Click to expand...
Click to collapse
That question does not really have two answers; you *can* roll back the system/bootloaders/firmware, you *cannot* roll back the userdata, which means that in order to retain the majority of your data, you would have to restore userdata from a backup, and that, of course, will only contain the data up to the point that the backup was made.
Anti-rollback features really only apply to someone trying to take advantage of an old security vulnerability by "upgrading" to an older system build. You can't do that on a locked system.
For what it's worth: Yes; if you have an unlocked bootloader.
Code:
fastboot unlock_critical
is a must (flash-all writes over the bootloader)
If everything is unlocked, it is as simple as:
(from the directory the 8.1 factory image is extraced to)
Code:
adb reboot bootloader
fastboot -aa
flash-all
(hold down vol-dn button when it gets to userdata and release once it boots back into bootloader)
Code:
fastboot -ab
flash-all
Once complete it should boot into Oreo.
...obviously this will not work on Verizon devices.
Thank you gentleman. Now I have ammo for when someone says your can't downgrade!
Hi there,
Just like the title says.
Xprivacylua won't' work on Android 13 for me. what I was wondering is whether I can downgrade without flashing the bootloader.
I am going to follow the following guide but am afraid to get a bricked phone
How to Bypass Anti Rollback Mechanism in Pixel 6A/6/6 Pro
This guide will show you how to bypass Anti Rollback Mechanism while doing a downgrade from Android 13 to Android 12 on Pixel 6A/6/6 Pro.
www.droidwin.com
Thank you all
------------------------add---
finally managed to downgrade to Android 12, just add --force before update:
fastboot --force update image-oriole-sq3a.220705.001.b2.zip (m phone is pixel6)
then reboot, then choose factory reset.
credits @Bunnehbunn
If you do it, regardless if you succeed or fail, you and your phone shall forever be remembered. And this day
forth shall always be named bush911 Pixel 6 Pro Day. And it shall be written and stories will be told from one generation to the next.
If you do it, the inner Yoda in me tells me to tell you to make sure you flash BOTH slots. Godspeed.
smokejumper76 said:
If you do it, regardless if you succeed or fail, you and your phone shall forever be remembered. And this day
forth shall always be named bush911 Pixel 6 Pro Day. And it shall be written and stories will be told from one generation to the next.
If you do it, the inner Yoda in me tells me to tell you to make sure you flash BOTH slots. Godspeed.
Click to expand...
Click to collapse
You've made my day
I am going to wait and see for several days before proceeding as I just know how to flash-all, I have never flashed step by step or flashed to the specific slots.
I know that Android 12 worked just fine with Android 13's bootloader, but that was before I actually upgraded to 13. After I fully upgraded to 13, I wasn't willing to test downgrading everything but the bootloader since I would have to wipe in order to have app data be consistent with the Android version.
I'm pretty sure in my thread a user (sooooo many posts this week since the update, it's all running together) that yesterday a user reported that downgrading everything but the bootloader worked just fine. Android 12 worked fine. If you do this, remember to wipe (and have a backup of anything you want to keep from your internal storage), and downgrade on both slots, not just your active slot.
roirraW edor ehT said:
I'm pretty sure in my thread a user (sooooo many posts this week since the update, it's all running together) that yesterday a user reported that downgrading everything but the bootloader worked just fine. Android 12 worked fine.
Click to expand...
Click to collapse
Oh, I have to find that post. I knew someone was talking about trying that but didn't see that they actually did. Let's see how good of a friend search really is to me
roirraW edor ehT said:
I know that Android 12 worked just fine with Android 13's bootloader, but that was before I actually upgraded to 13. After I fully upgraded to 13, I wasn't willing to test downgrading everything but the bootloader since I would have to wipe in order to have app data be consistent with the Android version.
I'm pretty sure in my thread a user (sooooo many posts this week since the update, it's all running together) that yesterday a user reported that downgrading everything but the bootloader worked just fine. Android 12 worked fine. If you do this, remember to wipe (and have a backup of anything you want to keep from your internal storage), and downgrade on both slots, not just your active slot.
Click to expand...
Click to collapse
Is downgrading on both slots a must? I have just flashed Android 13 bootloader on both slots. For now chrome (stable, beta and development) keeps crashing. I can't even finish writing this reply on Chrome.
tried clearing the cache, restarting etc., ended up with no luck . It turned out that Chrome often closes itself within no more than 5 minutes of browsing after downloading to Android 12
Post before crashing
.
bush911 said:
Is downgrading on both slots a must?
Click to expand...
Click to collapse
If you want to run Android 12 instead of 13, and you've already flashed 13 to both slots, or at least 13's bootloader to both slots (which you should definitely do if you haven't), then yes, you should downgrade both slots and wipe to start fresh.
You can't expect both Android 12 and Android 13 to operate with the same app data, so having a different version of Android on the other slot isn't going to do you any favors.
bush911 said:
I have just flashed Android 13 bootloader on both slots. For now chrome (stable, beta and development) keeps crashing. I can't even finish writing this reply on Chrome.
tried clearing the cache, restarting etc., ended up with no luck . It turned out that Chrome often closes itself within no more than 5 minutes of browsing after downloading to Android 12
Post before crashing
.
Click to expand...
Click to collapse
Try a factory reset?
Lughnasadh said:
Oh, I have to find that post. I knew someone was talking about trying that but didn't see that they actually did. Let's see how good of a friend search really is to me
Click to expand...
Click to collapse
Here my friend. Also in the OP.
Partial quote:
I tried this as soon as I upgraded to 13 and yes you can downgrade down to Android 12 after upgrading with no noticable issues. The radio and every other image but the bootloader can be downgraded. But I only tried 003, 004 July images for oriole so I don't know about anything lower personally.
Click to expand...
Click to collapse
roirraW edor ehT said:
Here my friend. Also in the OP.
Partial quote:
Click to expand...
Click to collapse
Ok, you are now officially a better friend to me than search is. Sorry search...
Thank you!!!
Lughnasadh said:
Ok, you are now officially a better friend to me than search is. Sorry search...
Thank you!!!
Click to expand...
Click to collapse
You can join the ranks of such like my boss at work (where we use Google officially for everything including company mail). They chat me to ask me for a link to a particular file that's in Google Drive, or to find a particular email for them.
Just kidding about joining the ranks! You're welcome!
roirraW edor ehT said:
Here my friend. Also in the OP.
Partial quote:
Click to expand...
Click to collapse
I guess it would just as easy to remove the bootloader line from the flash-all.bat script and just use flash-all???
It's good to know for sure that we can downgrade though and that it's only the bootloader version that is important and not other parts of the OS.
Lughnasadh said:
I guess it would just as easy to remove the bootloader line from the flash-all.bat script and just use flash-all???
It's good to know for sure that we can downgrade though and that it's only the bootloader version that is important and not other parts of the OS.
Click to expand...
Click to collapse
Absolutely, I agree on both parts.
Hi, I have a question here, as long as I don't update the latest bootloader (>= 1.2 ?), it shouldn't trigger the anti rollback mechanism? My pixel 6 with Android 13 now has a bootloader version of oriole-slider-1.1-8167057, but the bootloader version in this official page has been updated to slider-1.2-8739948.
I pulled the AOSP 13 (branch android-13.0.0_r2), built it locally (userdebug mode), and flashed it without the bootloader because there is no bootloader.img in the build output. And the phone successfully booted.
I've never flashed the Android 13 factory image, so i got away with the risk of ARB?
enderdzz said:
Hi, I have a question here, as long as I don't update the latest bootloader (>= 1.2 ?), it shouldn't trigger the anti rollback mechanism? My pixel 6 with Android 13 now has a bootloader version of oriole-slider-1.1-8167057, but the bootloader version in this official page has been updated to slider-1.2-8739948.
I pulled the AOSP 13 (branch android-13.0.0_r2), built it locally (userdebug mode), and flashed it without the bootloader because there is no bootloader.img in the build output. And the phone successfully booted.
I've never flashed the Android 13 factory image, so i got away with the risk of ARB?
Click to expand...
Click to collapse
I'm surprised with that old of a bootloader you were able to boot Android 13, you're running a bootloader from April. Also I'm surprised you weren't bricked after booting Android 13 because it does increment the anti-rollback counter.
https://cs.android.com/android/platform/superproject/+/android-13.0.0_r2:device/google/gs101/interfaces/boot/1.2/BootControl.cpp;l=226
drivers/soc/google/boot_control/boot_control_sysfs.c - kernel/gs - Git at Google
I'm guessing your bootloader version is old enough to not have the bits implemented so it just doesn't care, but that's weird because the July Android 12 bootloaders do have the bits and will not load if the counter is incremented by Android 13.
I wouldn't recommend continuing to run like this and would update to the August Android 13 bootloader because there's no telling what might be happening wrong under the hood. Example is that the August Android 13 bootloader it is able to boot Android 12 but because of interface differences it is a broken experience.
June 20, 2023 TQ3A.230605.010.A1 T-Mobile/MVNOs / June 13, 2023 TQ3A.230605.010 Global - Root Pixel 6 Pro [Raven]
Pixel 6 Pro [Raven] Updated May 13, 2023 Note that more than three users have said that 34.0.1 (even May 10, 2023's binary update of 34.0.1) did not work correctly for them. I recommend sticking with 33.0.3 (just below these quotes) Someone...
forum.xda-developers.com
So yeah if you're correct then it's possible you did get away with it as your firmware is too old to have implemented it. However this is not a supported firmware-software configuration.
Thank you for your reply!
Namelesswonder said:
I'm surprised with that old of a bootloader you were able to boot Android 13, you're running a bootloader from April.
Click to expand...
Click to collapse
Yeah. This bootloader came from the factory image `oriole-sp2a.220405.004`.
Namelesswonder said:
https://cs.android.com/android/platform/superproject/+/android-13.0.0_r2:device/google/gs101/interfaces/boot/1.2/BootControl.cpp;l=226
Click to expand...
Click to collapse
I also noticed this piece of code, but I'm not sure if it was compiled into bootloader.img or boot.img? If it's in bootloader.img, that's a good explanation, because I didn't flash this version (after June) of bootloader so the A13 now isn't restricted by anti-rollback.
BTW I am also curious why the device is not flashed bootloader.img when running `fastboot flashall -w`, even though there is a compiled bootloader.img file in the output directory.
enderdzz said:
Thank you for your reply!
Yeah. This bootloader came from the factory image `oriole-sp2a.220405.004`.
I also noticed this piece of code, but I'm not sure if it was compiled into bootloader.img or boot.img? If it's in bootloader.img, that's a good explanation, because I didn't flash this version (after June) of bootloader so the A13 now isn't restricted by anti-rollback.
BTW I am also curious why the device is not flashed bootloader.img when running `fastboot flashall -w`, even though there is a compiled bootloader.img file in the output directory.
Click to expand...
Click to collapse
That code is not in the bootloader, the bootloader is closed source. The code is part of the bootcontrolhal ([email protected]) on Android and runs on a successful boot of Android. The other code is the sysfs device being called by the HAL, that code is in the kernel.
I don't know if your device actually had the anti-rollback counter incremented, because a system monitor call is made and the source code for TZ/TEE/Titan are also closed source. Your device might've never incremented the counter because the firmware used by them just don't have the ability to, but it's just speculation.
And flashall doesn't flash bootloaders or radios, it only flashes Android system partitions defined by the product information. You can follow the steps here to flash them.
June 20, 2023 TQ3A.230605.010.A1 T-Mobile/MVNOs / June 13, 2023 TQ3A.230605.010 Global - Root Pixel 6 Pro [Raven]
Pixel 6 Pro [Raven] Updated May 13, 2023 Note that more than three users have said that 34.0.1 (even May 10, 2023's binary update of 34.0.1) did not work correctly for them. I recommend sticking with 33.0.3 (just below these quotes) Someone...
forum.xda-developers.com
Namelesswonder said:
That code is not in the bootloader, the bootloader is closed source. The code is part of the bootcontrolhal ([email protected]) on Android and runs on a successful boot of Android. The other code is the sysfs device being called by the HAL, that code is in the kernel.
I don't know if your device actually had the anti-rollback counter incremented, because a system monitor call is made and the source code for TZ/TEE/Titan are also closed source. Your device might've never incremented the counter because the firmware used by them just don't have the ability to, but it's just speculation.
And flashall doesn't flash bootloaders or radios, it only flashes Android system partitions defined by the product information. You can follow the steps here to flash them.
June 20, 2023 TQ3A.230605.010.A1 T-Mobile/MVNOs / June 13, 2023 TQ3A.230605.010 Global - Root Pixel 6 Pro [Raven]
Pixel 6 Pro [Raven] Updated May 13, 2023 Note that more than three users have said that 34.0.1 (even May 10, 2023's binary update of 34.0.1) did not work correctly for them. I recommend sticking with 33.0.3 (just below these quotes) Someone...
forum.xda-developers.com
Click to expand...
Click to collapse
Thank you very much! I'm much more clear now.
enderdzz said:
Thank you very much! I'm much more clear now.
Click to expand...
Click to collapse
That's good.
Have a question, while you were on Android 13 with the Android 12 bootloader, was everything working right? Nothing crashing or throwing errors? With the Android 13 bootloader on Android 12 having issues with DRM and web browsers crashing it would be interesting to know if the same was also true for you when you were on the opposite scenario.
Namelesswonder said:
That's good.
Have a question, while you were on Android 13 with the Android 12 bootloader, was everything working right? Nothing crashing or throwing errors? With the Android 13 bootloader on Android 12 having issues with DRM and web browsers crashing it would be interesting to know if the same was also true for you when you were on the opposite scenario.
Click to expand...
Click to collapse
Yes, I'm also interested in this topic.
I've only tested webview browser tester 101.0.4951.61 and NNAPI. No problems found so far. I will update here if I encounter any new problems
I'll experience it deeply, won't flash another system or bootloader for a while. Since I flashed the userdebug version, which I think is not as feature-rich as the factory image, but it let me have root access.
I also checked `dmesg` info and didn't find anything abnormal except that it keeps reporting `init: Control message: Could not find 'aidl/android.hardware.biometrics.fingerprint.IFingerprint/default' for ctl .interface_start from pid: 467 (/system/bin/servicemanager)`, I think it's not a big deal. And no useful log about the anti-rollback counter, which maybe needs some reverse engineering.
enderdzz said:
Yes, I'm also interested in this topic.
I've only tested webview browser tester 101.0.4951.61 and NNAPI. No problems found so far. I will update here if I encounter any new problems
I'll experience it deeply, won't flash another system or bootloader for a while. Since I flashed the userdebug version, which I think is not as feature-rich as the factory image, but it let me have root access.
I also checked `dmesg` info and didn't find anything abnormal except that it keeps reporting `init: Control message: Could not find 'aidl/android.hardware.biometrics.fingerprint.IFingerprint/default' for ctl .interface_start from pid: 467 (/system/bin/servicemanager)`, I think it's not a big deal. And no useful log about the anti-rollback counter, which maybe needs some reverse engineering.
Click to expand...
Click to collapse
If WebView applications didn't crash within minutes of launching them then that means the DRM library should either be working or just not segfaulting like it does with Android 12 on 13 bootloader.
The fingerprint scanner HAL not working is completely understandable, part of the bootloader flash also carries the fingerprint scanner's firmware, and we know that one of the big things with Android 13 is that the fingerprint scanner is somewhat more reliable, so it definitely has changed between Android 12 to 13.
Interesting stuff, will be cool to see where it can go, but man is it sketchy to recommend people still on Android 12 to downgrade to April and then try flashing the Android 13 system images, real possibility of making bricks.