How To Guide April 17, 2024 AP1A.240405.002.B1 Global - Unlock bootloader / Root Pixel 7 Pro [Cheetah] / SafetyNet

[i5lee8bit]

My Pixel 7 is the first phone I've run rooted since my OnePlus 6T on Android 9. It appears the process to OTA update has changed since the last time I did it a few years ago. If I follow the steps in post #2 of this thread to update (running modified flash-all.bat w/ full factory image, patching the init_boot.img in Magisk, flashing patched .img), will this automatically put the new images on the inactive slot then switch it to active? Or do I need to manually switch slots first then run flash-all.bat?

You don't need to switch slots manually, generally ever, when updating your phone. If you flash full factory image, it'll just install over your current active slot and done. If you sideload OTA zip, it'll flash to the other slot and change slots for you and boot (you won't even notice it happening tbh).

One question though: are you currently running with verity/verification disabled? If you don't know what I'm talking about, it's probably a "no", but keep in mind if you want to flash a custom kernel for this device you'll need to disable them. And unfortunately that will require a data wipe the first time you do it, and then you need to remember to disable again each time you update on future updates. There's a very slim chance they'll find a workaround to needing them disabled eventually but I wouldn't count on it. More info on this can be found in the OP's and kernel development threads (e.g. Kirisakura). If you don't care about flashing custom kernels, simply disregard this last point and the next.

But my major reason for that last point is that if you are running verity and verification disabled, in that case you may want to manually switch slots and flash full factory image with v/v disabled as a means of being overcautious. My reasoning for this is that you never know when you may run into a bootloop from a bad flash, which will automatically trigger an active slot switch, and once it attempts to boot without those flags disabled, you're beat and have to wipe. So out of an abundance of caution, I flashed both slots last month with the flags disabled.

 

[sharksfan7]

Thanks, @i5lee8bit. When I rooted my P7, I don't think I did anything to disable verity/verification. I just patched/flashed the init_boot.img then configured some stuff in Magisk. I don't plan on running a custom kernel.

I didn't think I could sideload just the OTA being rooted. Thought I needed to flash the full factory image and re-root. It's been a while since I've done this. Looks like I need to do a bit more research before I do this update.

 

[simplepinoi177]

Learning about Pixel OTAs + retain root.
* Unhide Magisk + disable modules
* Flash stock init_boot.img
* OTA or OTA side load
* Re-patch / flash init_boot.img

Question on side load. Google says to check System update before side loading?
I'm still on Oct - Pixel took it upon itself to start downloaded and I paused it.
Upon reviewing it shows resume...without any build info which I find annoying - pretty sure wants to update to Nov. It OK to sideload OTA in this paused state?

Which leads my 2nd question - is it that OTA via phone always incremental / delta. IE I need Nov OTA before Dec. 2 separate updates in this case?
But side load OTAs are full so one can jump to latest release via single ota side load?

I'm kinda leaning toward only dealing update / re-root quarterly so prefer the single update. Would also like to know how to block OTA check / auto download. Anything native or can I block with afwall+? (Auto updates was disabled in dev options but it still began downloading anyway)

Lastly will safeynet fixes periodically get broken with OTAs?

Thanks

Sorry I can't answer much of your questions; I just wanted to answer what I can and hope to bump your post a bit so maybe it can be answered by experts better than I.
I am not certain as for your first question (so please just take it as my opinion and don't base further action from it), I imagine Google anticipates such actions that by sideloading OTAs would cancel/invalidate whatever partial/paused OTA is currently being downloaded. If anything, I imagine it would only be troublesome if it was in the process of "installing", but if you paused it early on, most likely it was still downloading and/or I doubt you could pause it once it was actually in the middle of installing.
As for your second question (again, just my opinion and do not base further action from it), I imagine OTA's, although incremental, carry-over and/or include whatever improvements the previous OTA's had and it merely modifies & works-on the core system and much of it isn't really touched outside what the OTA patches so applying each update step-by-step isn't really applied to much of the core system. In the end, what I'm implying is that if I were in your position, I, myself, would not apply each OTA from what version you are in to current -- I would merely install the latest OTA only.
Honestly, if you are concerned with the incremental differences OTA's apply and are going to sideload them anyways and you mentioned you'd like to update it quarterly and prefer a "single update", you should consider flashing the full factory images instead of the OTA's. You have to open up a command prompt and run commands anyways (also you would need to if you plan to re-root), the major differences is you run commands in the bootloader mode (than recovery mode) and run a few more commands (fastboot than adb); one other important addition is you MUST remove "-w" from the flash-all script to keep your data -- but that's basically it. Again, this case & opinion only applies if you are sideloading OTA's, un-rooting and implementing the (very fairly slow, although it's been announced it has been more streamlined and process time has been cut down significantly) System Update in the OS would not need you using the adb command (necessarily) and downloading & applying images.
One other thing I might mention since you mention "Pixel OTAs + retain root" (even if it seems you know this info already, but take it as a reminder if that's the case) is you are unable to apply the OTA through System Update if you are rooted as well as once you apply the OTA (or Factory Image), you will lose root; there is (currently) no way to apply the OTA and "retain root" -- it must be re-applied.
As for your inquiry about blocking the OTA check/auto-download, roirraW "edor" ehT touched on the topic and pointed to a post that might be applicable back in post #1318. It might do and/or at least point you in the right direction.
Lastly, yes, sometimes the firmware & OTA updates break things related to root and bypassing root checks, but you can always count on it being reported/discussed here and can keep updated on things and its progress here -- but such is the risk of rooting and keeping the device up-to-date. Depending on the "damage", it's usually dealt with swiftly enough...the great developers that work on aspects of this device, Android OS, and Magisk work ever so diligently...

Thanks, @i5lee8bit. When I rooted my P7, I don't think I did anything to disable verity/verification. I just patched/flashed the init_boot.img then configured some stuff in Magisk. I don't plan on running a custom kernel.

I didn't think I could sideload just the OTA being rooted. Thought I needed to flash the full factory image and re-root. It's been a while since I've done this. Looks like I need to do a bit more research before I do this update.

I could be completely wrong, but I don't believe you need to be unrooted to sideload the OTA; you only need to be unrooted if you plan on using the System Update in the OS. BUT, regardless, in all options, root is lost and must always re-root afterwards. As I said with taysandman, I implore you to seriously consider still updating using the Full Factory images rather than sideloading the OTA merely because the Full Factory is a superior update (@roirraW "edor" ehT explains it best) as well as sideloading the OTA is not that much different or far-fetched from updating using the Full Factory image (both have to download images, open a command prompt, run commands, and you'd have to open/run fastboot to re-root anyway) -- the only big differences is it being done in bootloader mode instead of recovery, fastboot commands instead of adb, and you must modify the flash-all script before running it.


Apologies for the wordiness, but I hope it helps...

 

[otonieru]

Is it just me or I can't seem to find the new Security& Privacy hub, and the Google One VPN is still not activated after the December update? Maybe it has to do with the safetynet module in magisk?

For me who is on Singapore unit,

i will never get those One VPN, sad story.

 

[kornball]

With the update to battery usage in Settings, is the graph gone for anyone else? Everything is properly listed in usage since last full charge, but there is no longer any sort of graph.

 

[vlubosh]

With the update to battery usage in Settings, is the graph gone for anyone else? Everything is properly listed in usage since last full charge, but there is no longer any sort of graph.

wait few hours, it will be there, the same was with latest BETA

 

[Techboyz97]

I was on T1B3.221003.008. I received an update yesterday night. Now I'm on TQ1A.221205.011 but I don't see the changes. Exemple : the battery usage graph shows the full charge on a day and not up to 7 days. The Security and Privacy are separated and not merged.

 

[vurtomatic]

I thought I used to be able to tap the battery icon in the status bar to open battery settings. That seems to be gone after the Dec update?

 

[Lughnasadh]

I was on T1B3.221003.008. I received an update yesterday night. Now I'm on TQ1A.221205.011 but I don't see the changes. Exemple : the battery usage graph shows the full charge on a day and not up to 7 days. The Security and Privacy are separated and not merged.

Some of the changes likely require a server side update, Google Play System update, Google Play Services update or the like.

 

[taysandman]

Sorry I can't answer much of your questions; I just wanted to answer what I can and hope to bump your post a bit so maybe it can be answered by experts better than I.
I am not certain as for your first question (so please just take it as my opinion and don't base further action from it), I imagine Google anticipates such actions that by sideloading OTAs would cancel/invalidate whatever partial/paused OTA is currently being downloaded. If anything, I imagine it would only be troublesome if it was in the process of "installing", but if you paused it early on, most likely it was still downloading and/or I doubt you could pause it once it was actually in the middle of installing.
As for your second question (again, just my opinion and do not base further action from it), I imagine OTA's, although incremental, carry-over and/or include whatever improvements the previous OTA's had and it merely modifies & works-on the core system and much of it isn't really touched outside what the OTA patches so applying each update step-by-step isn't really applied to much of the core system. In the end, what I'm implying is that if I were in your position, I, myself, would not apply each OTA from what version you are in to current -- I would merely install the latest OTA only.
Honestly, if you are concerned with the incremental differences OTA's apply and are going to sideload them anyways and you mentioned you'd like to update it quarterly and prefer a "single update", you should consider flashing the full factory images instead of the OTA's. You have to open up a command prompt and run commands anyways (also you would need to if you plan to re-root), the major differences is you run commands in the bootloader mode (than recovery mode) and run a few more commands (fastboot than adb); one other important addition is you MUST remove "-w" from the flash-all script to keep your data -- but that's basically it. Again, this case & opinion only applies if you are sideloading OTA's, un-rooting and implementing the (very fairly slow, although it's been announced it has been more streamlined and process time has been cut down significantly) System Update in the OS would not need you using the adb command (necessarily) and downloading & applying images.
One other thing I might mention since you mention "Pixel OTAs + retain root" (even if it seems you know this info already, but take it as a reminder if that's the case) is you are unable to apply the OTA through System Update if you are rooted as well as once you apply the OTA (or Factory Image), you will lose root; there is (currently) no way to apply the OTA and "retain root" -- it must be re-applied.
As for your inquiry about blocking the OTA check/auto-download, roirraW "edor" ehT touched on the topic and pointed to a post that might be applicable back in post #1318. It might do and/or at least point you in the right direction.
Lastly, yes, sometimes the firmware & OTA updates break things related to root and bypassing root checks, but you can always count on it being reported/discussed here and can keep updated on things and its progress here -- but such is the risk of rooting and keeping the device up-to-date. Depending on the "damage", it's usually dealt with swiftly enough...the great developers that work on aspects of this device, Android OS, and Magisk work ever so diligently...

I could be completely wrong, but I don't believe you need to be unrooted to sideload the OTA; you only need to be unrooted if you plan on using the System Update in the OS. BUT, regardless, in all options, root is lost and must always re-root afterwards. As I said with taysandman, I implore you to seriously consider still updating using the Full Factory images rather than sideloading the OTA merely because the Full Factory is a superior update (@roirraW "edor" ehT explains it best) as well as sideloading the OTA is not that much different or far-fetched from updating using the Full Factory image (both have to download images, open a command prompt, run commands, and you'd have to open/run fastboot to re-root anyway) -- the only big differences is it being done in bootloader mode instead of recovery, fastboot commands instead of adb, and you must modify the flash-all script before running it.


Apologies for the wordiness, but I hope it helps...

Thanks.

I believe your correct it was just downloading OTA which was paused and shouldn't impact OTA side load. Just Google pointing it out made me wonder...

You're right my terminology was wrong. Retain data and re-root.

My only thought on full factory images vs OTAs via phone is that the Nov update showed ~30MB download. Yet looking at factory images over ~2.5GB. That's a big difference to write to nand storage to gain 30MB worth of security updates. So been curious about OTAs to help extend Pixels life. (Haven't actually looked if Google gives any write endurance specs on Pixel.)

However I did end up using Google's chrome flash tool to update to Dec last night. (Factory image) Didn't unroot. Just disable modules and unhide magisk and flash. Upon boot magisk was uninstalled. Re-install Magisk and re-patch init_boot. Re-enable modules. All went well including safetynet. I really do hope the guru devs over at TWRP will grace us with Pixel 7 / 6 support. Image backups help calm the nerves when doing system updates.

Regarding root after update I briefly read a few guides I believe mentioning "keeping root" with update. Pre-downloading the factory image + init_boot patch. Then re-packing factory image's zip to include patched init_boot. Allegedly flashing all in single update.

Thanks for suggestions. I'll explore roirraW "edor" #1318 to completely disable auto OTAs.

Coming from VZW note 8 which had to stay on Android 7 for last 5+ yrs to keep root. So quite rusty on these OTA things.

 

[waldoud]

Hello everyone, I have a question, what difference would there be between the uk and the global, can this version change be done?

 

[simplepinoi177]

My only thought on full factory images vs OTAs via phone is that the Nov update showed ~30MB download. Yet looking at factory images over ~2.5GB. That's a big difference to write to nand storage to gain 30MB worth of security updates. So been curious about OTAs to help extend Pixels life. (Haven't actually looked if Google gives any write endurance specs on Pixel.

As I understood the twitter post roirraW "edor" ehT posted about in post #1438, OTA's can be more than the simple size (~30MB in this instance) it posts in the System Update page in the OS. Updating through OTA can take painstakingly long; it felt like 30 minutes when I did it once on my wife's unrooted phone. Also, (according to the twitter post) it seems to depend a lot on its compression when it comes to processing. Depending on your internet speed, if you can download the 2.5GB relatively quickly (Google's servers have always been lightening in my experience), flashing the full factory is faster than the device slowly downloading the 30MB (I don't know why it took so long to download the 30MB) and then uncompressing and then installing/processing the OTA update. Running the flash-all on the Full Factory Image is usually finished in under 2 minutes (in my experience, YMMV). Also, it's not like you have to load the 2.5GB on the phone, just on your computer. Also, again, @roirraW "edor" ehT explains it best on how flashing and laying down the whole system image as an update is better than incrementally applying little patches over time. In one update it might just be 30MB worth of updates/changes, but after (let's say 4) months of around 30MB here and there, it adds up to 120MB months of incremental and intermittent data being patched here and there in variable places. Sorry I'm not explaining it well, i'm hoping the rode warrior can...

Regarding root after update I briefly read a few guides I believe mentioning "keeping root" with update. Pre-downloading the factory image + init_boot patch. Then re-packing factory image's zip to include patched init_boot. Allegedly flashing all in single update.

I think I've seen something like that; but from what I can recall on the instance I saw it, it was for a specific circumstance of attempting to repair a messed up partition and/or it was just put up in theory as a thought experiment. Now, I could be completely wrong so I hope some expert would come and correct me if I am, but I recall momentarily seeing that when running the flash-all command process, it checks and "validates" the partitions on the device and it may check it against the image files in the Factory Image zip. If I'm correct and that's true (again, I am completely guessing and could be completely wrong and hope an expert would correct if I am), then messing with the init_boot image file and changing it from what is stock may incur some bad juju; in my head I imagine it akin to checksums not matching. I dunno, just a thought/guess/concern

In any case, I'm happy it all worked out for you and I'm glad I could help some...

Hello everyone, I have a question, what difference would there be between the uk and the global, can this version change be done?

If you had already flashed the global and wished to flash the UK one (or vice-versa), as I understand it, you can simply dirty-flash it over whatever is already installed/flashed. For November, I flashed/installed the Global, but wanted to install the Verizon one, and was told & able to just flash the Verizon one over the Global one with no issues.
If you are asking for a complete explanation on the difference between the two, that's a different question I am willing to let someone else answer

 

[linuxares]

Hi!

Anyone know why with the OTAs my phone won't even start installing/downloading them? It like instantly "nopes" when I try to download.

I have no clue why since it doesn't give me any information what have gone wrong.

EDIT: I run the Telia version for November so might be why?

EDIT2: Found the issue. Magisk init_boot wasn't loved by the OTA updater. Restored the image file now it OTA updates.

 

[madmuthertrucker]

I was wondering if I could switch slots before flashing each new update? kind of like what the phone does when it gets the OTAs.

 

[proxyx]

After flashing Q1A.221205.011 to slot A on my P7P, I attempted to flash the same to slot B. However, when I attempt to do so and issue the "fastboot reboot bootloader "command, the P7P hangs at a black screen and eventually reboots to slot A. Im never able to flash-all on slot B because I can't get to it. Is this recoverable? Seems like without slot B i run the risk of a bricked device if something were to happen to slot A.

 

[Lughnasadh]

After flashing Q1A.221205.011 to slot A on my P7P, I attempted to flash the same to slot B. However, when I attempt to do so and issue the "fastboot reboot bootloader "command, the P7P hangs at a black screen and eventually reboots to slot A. Im never able to flash-all on slot B because I can't get to it. Is this recoverable? Seems like without slot B i run the risk of a bricked device if something were to happen to slot A.

What commands and in what order are you giving?

This should work:

adb reboot bootloader
fastboot --set-active=b (Since you are currently on slot a)
fastboot getvar current-slot (To confirm you are now on slot b)
flash-all.bat

 

[proxyx]

What commands and in what order are you giving?

This should work:

adb reboot bootloader
fastboot --set-active=b (Since you are currently on slot a)
fastboot getvar current-slot (To confirm you are now on slot b)
flash-all.bat

Yes that's the order of operations that I performed. I just tried the following:

adb reboot bootloader
fastboot --set-active=b
fastboot continue

and that gave a black screen and I noticed a couple of times a line flashed at the bottom of the screen then it eventually rebooted to slot A. Is slot B corrupted? If so, any way to recover?

 

[proxyx]

Yes that's the order of operations that I performed. I just tried the following:

adb reboot bootloader
fastboot --set-active=b
fastboot continue

and that gave a black screen and I noticed a couple of times a line flashed at the bottom of the screen then it eventually rebooted to slot A. Is slot B corrupted? If so, any way to recover?

Got it to flash. Thank you very much for your input!

 

[Lughnasadh]

Yes that's the order of operations that I performed. I just tried the following:

adb reboot bootloader
fastboot --set-active=b
fastboot continue

and that gave a black screen and I noticed a couple of times a line flashed at the bottom of the screen then it eventually rebooted to slot A. Is slot B corrupted? If so, any way to recover?

So you did exactly the commands I gave you?

 

[Lughnasadh]

Got it to flash. Thank you very much for your input!

Glad you got it to flash! Just to be clear, did you get it to flash by issuing the exact commands I gave you or did you do something else?