yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] badabing2003:
That works for OTA, but if for any stupid reason the active slot somehow gets corrupted, then the system is unuseable (not necessarily unrecoverable).

As a modder, considering that we mock with the phone a lot, it's prudent that our first flash is to both slots.

After that, it's a good practice to flash to inactive slot, even when doing factory image based flashing to make sure we always have something recent to fallback on in case anything goes wrong.

All one has to do is change slots before doing the flash_all
[Google Pixel 7 Pro] BIGWORM:
Just in case anyone was wondering on TMO:

I was able to get mine unlocked through TFORCE on Twitter in something around 10 minutes. Just told them I'm going out of the country for 6 weeks, and they unlocked the phone, no question. This is the 3rd time I've done this, having worked previously with my OnePlus 6T and 8T, but at least this time, I don't have to pull a freakin' token and send it to OnePlus then wait to flash a bin flash they would send!
[Google Pixel 7 Pro] Lughnasadh:
Yeah, this is exactly what I was thinking and why when I found out I had no radio on my inactive slot I immediately flashed the factory image to that slot. There is no reason why a phone should ship with firmware on only one slot since obviously OTAs can be taken when a slot is full.

In this circumstance, however, I think it was just the radio that was missing as I believe there was a bootloader image reported on that inactive slot. Still very disconcerting, especially in your scenario where if something should happen to make the active slot unbootable.
[Google Pixel 7 Pro] collegencmc:
Hey All,

So thanks to roirraW I was able to root my 7 pro after doing:

fastboot flash init_boot magisk_patched-xx.img

however I'm findings some app's think I'm rooted even though they are apart of the DenyList, also Adaway isn't blocking any ads any more. Is there another step I need to do? I know I'm rooted because I can adb shell-> su-> props (MagiskHidePropsConf) to allow for wifi tethering.

Thanks,
[Google Pixel 7 Pro] roirraW "edor" ehT:
Hi, did you follow all the rest of the steps in the SafetyNet section of Post #2? Most specifically, the version of the Universal SafetyNet Fix to install.

I wouldn't be able to say about AdAway. Maybe they need to update it to work with the Pixel 7 Pro - I'm not currently using it.
[Google Pixel 7 Pro] Lughnasadh:
Adaway is working fine for me 👍
[Google Pixel 7 Pro] collegencmc:
So I'm using: safetynet-fix-v2.3.1-api33.zip found here: https://xdaforums.com/t/unlock-boot...gain-all-relevant-links.4502805/post-87579103

I tired using safetynet-fix-v2.3.1-MOD_2.0.1.zip but it failed CTS. Let me try: safetynet-fix-v2.3.1-MOD_2.0.zip and I will report back. Thx for the help!! :D

Update: So now I'm on safetynet-fix-v2.3.1-MOD_2.0.zip but it still doesn't enforce DenyList on all apps :( but does pass all Safetynet test. Will keep an eye out for updates to it.

Let me know if any other ideas in mean time. Thanks again!!
[Google Pixel 7 Pro] PurppleMonkey:
Just for information, when you say the command wipes the phone, do you mean it erases everything?

Maybe I'll try with the official google tool after unlocking the bootloader!

Can we buy you a coffee by making a donation somewhere?

Ok Thanks !

Yes exactly, the command prompt asked me to download the latest version of platform-tools while I already have the latest version (33.0.3) on my MAC (with M1 chip).

It was not PF that alerted me, but the command prompt following this tutorial when I first tried the "flash-all.sh" command

This is the message received from the command prompt, not PF
[Google Pixel 7 Pro] PurppleMonkey:
This message is from the command prompt. I put you the screenshot of the line of code responsible for this error message (Line of code extracted from "Flash-all.sh"
[Google Pixel 7 Pro] Joeyxc:
There is a Google play system update available for the Pixel 7 pro finally. What precautions need to be taken to avoid losing root on reboot?
[Google Pixel 7 Pro] JakeDHS07:
Those should never cause root to be lost from what I understand. They don't overwrite any of the rooted partitions.
[Google Pixel 7 Pro] eg1122:
The update keeps failing on my end. Let me know if it goes through for you.
[Google Pixel 7 Pro] NepoRood:
Good points for sure, I was just spit balling, lol
[Google Pixel 7 Pro] Namelesswonder:
I just tested recently and the bootloader version doesn't report properly for the other slot. I did a last ditch effort with downgrading to solve my eio mode woes (which it did solve, strange that flashing over with same version and resetting didn't) and in the process I noticed that even when the bootloader on the other slot was a different version it would still report the currently booted version. So it's entirely possible that there is nothing on the other slot.

Before I did my last ditch effort I ordered a 256GB with the intent to return my current phone, so I guess I can test the hypothesis when it comes in. Hope it doesn't brick it. :)
[Google Pixel 7 Pro] pndwal:
Actually FWIW,

2nd slot ships w/o installed system

, but /system is filled w/ odex files for system apps which are loaded to /data the first time user boots the device...

Basically A/B seamless updates actually halved the size of the system partition

https://source.android.com/docs/core/ota/ab/ab_faqs#how-did-ab-affect-the-2016-pixel-partition-sizes

and that's how Google were able to do this; by leaving odex files out of active /system slot (these were consuming about half the space) and simply moving them to /data when user first boots the phone, most of the space needed for dual slots is actually recovered...

https://source.android.com/docs/cor...size-of-the-system-partition-without-squashfs

The cited article goes on to explain why this 'doesn't really' impact on /data... bit complex... And why this doesn't mean slower reboot after an OTA but does impact reboot time after Factory data reset etc...

👀 PW
[Google Pixel 7 Pro] Lughnasadh:
Yes, for sure. This is one of the characteristics of the A/B seamless updates implemented a while back. But this doesn't explain why there is no radio being reported on the inactive slot. And if indeed there is no radio, what other critical partitions may be missing? It's inconceivable that they would ship a new phone without a radio on both slots.

Interestingly though, after flashing the factory image to the inactive slot it did indeed report the correct baseband version, as expected.
[Google Pixel 7 Pro] roirraW "edor" ehT:
The "safetynet-fix-v2.3.1-MOD_2.0.zip" available from Displax' XDA post and website are the most recent official releases, so I curious where you found "safetynet-fix-v2.3.1-MOD_2.0.1.zip".

You had manually added the apps necessary to Magisk's DenyList, as per my SafetyNet instructions in Post #2?

Yes, the "-w" in fastboot -w update image-cheetah-td1a.220804.031.zip erases everything, just like a factory reset, which is why, normally when you update the phone with each month's latest firmware, you would normally remove the "-w".

No, but I appreciate the thought very much. I used to take donations years ago. I just like helping people the way I was helped when I first came to XDA. Thank you!

Ah! I should've loaded the flash-all.sh file and taken a look. I assumed it was nearly identical to the Windows flash-all.bat, but the .sh is different than the .bat. If I knew I was using the latest and it kept throwing that error, I would be tempted to take out those lines of the .sh, leaving you with:

#!/bin/sh

# 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.

fastboot flash bootloader bootloader-cheetah-cloudripper-1.0-9070028.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-cheetah-g5300g-220908-220908-b-9040061.img
fastboot reboot-bootloader
sleep 5
fastboot -w update image-cheetah-td1a.220804.031.zip

Thanks for the information and the screenshot.
[Google Pixel 7 Pro] PurppleMonkey:
TY.

Yes, that's what I did. But what I don't understand is why it displayed this error when I ran the command prompt in the "Platform-tools" folder downloaded from the official site in version 33.0.3... Interesting!

Well.. I just splurged, ordered a new one directly from google. He arrives tomorrow. I will follow your tutorial using PF after unlocking the Bootloader.

I have 2,5 questions:

1) on the command prompt, there is a way to know which version of platform-tools is used, on PF we can know it in advance?

2) When I run the command Flash-all.sh, normally I would go through all these steps (on MAC):

./fastboot flash bootloader bootloader-cheetah-cloudripper-1.0-9070028.img
./fastboot reboot-bootloader
sleeping 5
./fastboot radio flash radio-cheetah-g5300g-220908-220908-b-9040061.img
./fastboot reboot-bootloader
sleeping 5
./fastboot update image-cheetah-td1a.220804.031.zip

But, if in my case, like the first time, the process stops here:

./fastboot flash bootloader bootloader-cheetah-cloudripper-1.0-9070028.img
./fastboot reboot-bootloader

--What should I do ?

--Why wouldn't "Sleep 5" work for me?

EDIT : Instead of "cheetah" Mine, should be "Panther"
[Google Pixel 7 Pro] whatsisnametake2:
you have selected systemless hosts in magisk?
[Google Pixel 7 Pro] roirraW "edor" ehT:
You're welcome!

Indeed, no idea. I would emulate a mac and see what happens for me but it's not an easy task since I use Hyper-V a ton on my personal computer on a regular basis.

To be clear, my tutorial doesn't involve PixelFlasher at all. I've never used it. I use the manual method every month, and once or at the most twice used the Official Google Android Flash Tool instead when I had a weird issue, and I adjusted my instructions to indicate which two steps to skip if you're using this Android Flash Tool instead of the factory image (although you still need the factory image for the init_boot.img file).

The only way I know is to send the command:

adb /?

I don't know if it would be different at all on a Mac.

Spoiler content hidden.

So it does at least say 33.0.3. There doesn't seem to be a similar way for Fastboot, or at least not as easy. Anyone, please fill me in if there is a way - I don't have time to look into it right now.

For what it's worth, every month I rename my old platform-tools folder (the one I used to update to the previous month's firmware), and I freshly extract the latest platform-tools to a new folder, so everything's nice and clean - plus I keep the old firmware and files handy in case I need to flash back in a hurry.

I don't know enough about Macs to be able to help with that directly, but you can just copy and paste the individual commands at the right time yourself. Let yourself be the "sleeper". :)

You're using the correct factory image, then? The Panther one? You're scaring me by showing a copy and paste from the Cheetah flash-all.sh. :D

Ah! I forgot to put that step in my instructions! Thank you.

Edit: Added now. DOH me!
[Google Pixel 7 Pro] PurppleMonkey:
Hahahahah, You're right ! In this case, no need to specify a slot (a or b) or desable Verity and verification through prompt command ?

hahahaha yes, i just copied your text with cheetah inside ! Mine is Panther on my computer, no need to use your gun !
[Google Pixel 7 Pro] pndwal:
Why load anything in B slots if you're not going to ship with a working B system??... What's the point of unused baseband?...

As soon as you take an OTA, all necessary partitions are populated... With A/B Streaming update support the whole thing will necessarily be overwritten anyway; the update engine doesn't consider any data on B...

The delta differential payload algorithm simply uses blocks from active (A in this case) partition plus the delta payload (basically combines zero-filled block address info, unchanged block address info, binary blobs for new files and binary diff blobs for changed files) to produce the update by writing blocks directly to the B partition as they are read/downloaded...

What's on the inactive slot prior to an OS being installed there makes no difference.

Wouldn't expect anything else!...

🙂 PW
[Google Pixel 7 Pro] roirraW "edor" ehT:
The correct commands in post #2 are literal - there's no need to specify a slot, in which case, the currently active slot is the one that's flashed. If you opted to do anything at all with slots, as several users said recently in this thread, each month you flash a new factory image, you could change slots beforehand, but it's completely optional. I only list the steps you absolutely must take in my instructions.

The optional commands to switch slots are:

adb reboot bootloader
(wait for phone to boot into the bootloader / fastboot mode)

fastboot set_active other
fastboot reboot bootloader

then proceed with the commands from the flash-all.sh/flash-all.bat

The only part of my instructions that references that is the Optional next steps when updating - flashing custom kernels portion. Right now, if you plan on flashing a custom kernel - which is optional - you must disable those things and disabling Verification requires that you factory reset the device after, otherwise you'll get a screen that says the device is corrupted. All that's required to fix that is to factory reset, which again, will wipe everything.

The developers are working on getting the kernel flashing on the Pixel 7 Pro to a point where you at least don't need to disable Verification (disabling just Verity doesn't require a factory reset). This happened on the Pixel 6 Pro, too, and took a month or two before they developed a way for custom kernels to be able to be used without disabling either of those.

My advice is to wait, but it's completely up to you.

Note that if you disable them now, then every time you update the firmware (effectively, any time you run commands that end up flashing vbmeta.img, which the flash-all scripts do), you must re-disable them because the default action when flashing vbmeta.img is to enable them. If you forget to re-disable them, then if you disable them again later, you'll have to factory reset the device yet again.

Edit: You can also reference what I said about this subject recently here.

I figured, but I just wanted to make sure. :D LOL!
[Google Pixel 7 Pro] badabing2003:
You're right, the problem is not with OTA, Google also provides full firmware, with flash_all script, that script flashes into the current slot (of course this only applies to people like us who modify their phones, but still) and if anything goes wrong during that flashing, bad cable and what not, you're left with no bootable slot.

That's all, Google might not care about that scenario, hence we should flash to both slots the first time, or better yet, always flash to alternate slot each time we use flash_all.
[Google Pixel 7 Pro] badabing2003:
in Linux / Mac the command is sleep 5, all lower case

not sleeping and not Sleep
[Google Pixel 7 Pro] roirraW "edor" ehT:
Thanks for clearing that up!
[Google Pixel 7 Pro] Joeyxc:
Same here
[Google Pixel 7 Pro] Lughnasadh:
No phone should be shipped without both slots being bootable. If something happens to your active slot which makes it unbootable and you can't flash the firmware to the inactive slot, you're left with a brick. I see no reason why a phone should not be shipped with bootable firmware on both slots. Google is very aware that some users, and especially developers, may encounter these circumstances, particularly given their response to the new ARB fiasco concerning the Pixel 6/A13 update. Once you take your first OTA update (which I never do), both slots would be full anyway, so what's the point of not having bootable firmware on both slots out of the box?

Neither would I 😀
[Google Pixel 7 Pro] roirraW "edor" ehT:
The update seemed to work fine for me. Required a reboot after, but that's all. Says July 1, 2022, although I don't know what the date was before the update.
[Google Pixel 7 Pro] Lughnasadh:
Interesting. I keep getting "Failed to update", "Updates are temporarily unavailable. Try again later."

Never encountered that before. Maybe server problems or something. I'll try again later, as suggested 🤪
[Google Pixel 7 Pro] JakeDHS07:
Yeah it's definitely on Google's end. Give it a bit.
[Google Pixel 7 Pro] Lughnasadh:
Reminds me of a certain situation involving the Pixel 6 series, bootloaders and Android 13 🙃
[Google Pixel 7 Pro] capntrips:
The issue is you don't have fastboot on your PATH, so which fastboot returns nothing.

For example, if I remove it from my PATH and run flash-all.sh, I get the following:

./flash-all.sh: 17: --version: not found
./flash-all.sh: 17: [: -ge: unexpected operator
fastboot too old; please download the latest version at https://developer.android.com/studio/releases/platform-tools.html

Since you're running everything from a single folder, you would need to modify the relevant lines of the script to look something like this:

if ! [ $( ./fastboot --version | grep "version" | cut -c18-23 | sed 's/\.//g' ) -ge 3301 ]; then
echo "fastboot too old; please download the latest version at https://developer.android.com/studio/releases/platform-tools.html"
exit 1
fi

or just use PIxel Flasher
[Google Pixel 7 Pro] PurppleMonkey:
Thank you for your help !

What i have to do to add fastboot to my PATH and remove it (in case i have to remove it for an other version) ?
[Google Pixel 7 Pro] roirraW "edor" ehT:
I did a Google Search for adding platform tools to mac path.
[Google Pixel 7 Pro] capntrips:
You don't strictly have to put it on your PATH, but it can certainly be handy for situations exactly like this. As for how, I'll refer you to option 2 here.

Edit: on mobile, didn't see the above post until after
[Google Pixel 7 Pro] pndwal:
The value of modders flashiing both slots for safety prior to making risky changes is clear / a given, just like taking backups...

I'm not sure you even considered what I wrote/ linked since you keep saying "I see no reason why a phone should not be shipped with bootable firmware on both slots" however...

To reiterate:

Google are not selling phones to modders primary... These are generally for people who take Seamless OTAs, which is really why we have A/B...

Google are aiming to mandate A/B for holdouts like Samsung, and a key selling point is that devices need No more memory for the same device spec, ie. no extra cost...this is Google's agenda...

As I said, halving /system size goes a long way to achieving that spec with A and B slots and no more memory than an equivalent A only device, but in order to retain the performance benefits of factory odex files (which formerly doubled needed /system size) while reallocating the space they occupied, Google have been shipping devices with these files in the inactive B partition since the first Pixel!... That's how they've done it, and that's your reason they haven't shipped w/ OS on B... /system_b is full when shipped!

The files are moved to /data on first boot as explained, freeing up B only after device is set up...

So the alternatives are to ship without factory odex files for system apks... (That'd be a big performance hit, a hard sell to other OEMs and a backward step for A/B)... Or ship with these files in /system again and swallow the cost of doubling /system memory... (another hard sell for A/B...)

I guess it may be possible to ship with these files already in /data, but I'm sure that's been considered... I don't have an answer for that (except that a factory reset would remove these) but I doubt Google is going to change the system ('scuse pun) they've used since A/B's debut just to have an OS on B that most users will simply overwrite the first time they update...

Hope this is a bit clearer / makes some sense... 🙃 PW
[Google Pixel 7 Pro] i5lee8bit:
Gotta catch up on this thread later, but just an update - I'm trying to exchange my phone right now. On the phone with Google support 😩

Will post the update later and what happened with more detail. Needless to say, my problem came back. I know I mentioned before that my wife is currently pregnant, but we also have a 2 (almost 3) year old running around that I gotta take care of. So it's hard enough to keep up with my online interests, let alone a brand new phone wigging the hell out! 😭

Again a big thanks to everyone who threw in their 2 cents (or hundred bucks in some cases, lol), y'all know who you are. ❤️

edit: they're replacing with a 100% brand new factory sealed phone, no refurb yay. ensured me that I'd have more time for my trade-in (although it's a junk Pixel 3, so this part really doesn't matter, but it was nice to hear), but also that I won't lose the pre-order credit. they're sending me the new phone first so I return the current one AFTER i get the replacement which is great. after putting me on hold to speak with the hardware/troubleshooting department, she said no more steps were needed and they'll send out the replacement. she actually commended me for the troubleshooting steps I took :ROFLMAO: (obviously I left *certain* details out ;)). will also note, I do not have preferred care or premium One or whatever it's called. i guess i'm lucky with google support, because i always see so many horror stories but i always have generally good experiences... hopefully that last part doesn't get jinxed, lol.
[Google Pixel 7 Pro] collegencmc:
I don't remember where I think i got safetynet-fix-v2.3.1-MOD_2.0.1.zip maybe from an earlier post on here.

Yes I did, I will try a few more things and report back.

I would like to know do you know if:

safetynet-fix-v2.3.1-api33.zip found here: https://xdaforums.com/t/...gain-all-relevant-links.4502805/post-87579103

is safe (I mean I understand there was a risk) but wasn't sure if you know anything more about it? Also if I removed it and applied safetynet-fix-v2.3.1-MOD_2.0.zip am I still at risk for something if safetynet-fix-v2.3.1-api33.zip isn't safe?

Thanks!
[Google Pixel 7 Pro] NepoRood:
Makes total sense, the modding community is negligent compared to the average consumer base. And I'm pretty sure Google really doesn't care about us either, lol
[Google Pixel 7 Pro] roirraW "edor" ehT:
Thanks again for the update. Continued luck to you...

I can't really speak to any other files than the "official" MOD 2.0 - which works for me ever since Displax updated MOD 2.0 after the original MOD 2.0 had a typo that kept it from working. I didn't try the api33 one.

I did successfully use the "test" version Displax had uploaded before MOD 2.0 went official, and the test version was since deleted since MOD 2.0 supersedes it, although I think another user re-uploaded it in their post later.

I don't know anything about any of these files not being safe. As far as I know, they will either work or not work. No one mentioned anything about the api33 one not being safe, as far as I remember. I have no idea if it worked or not.

Sorry for the parts of the answers that are vague. :)
[Google Pixel 7 Pro] badabing2003:
I took a look at it, it is basically a modified version of the original safetynet-fix-v2.3.1 Fix by kdrag0n with the added code to drop the API level to 32 if it is >= 33.

Nothing harmful, but it does not include earlier Displax changes on top of v2.3.1

I'd just use the latest 2.0 from displax.
[Google Pixel 7 Pro] collegencmc:
Awesome thank you very much!! I'm going to try a wipe and reflash following your process to see if I can get to work that way. Thanks again!
[Google Pixel 7 Pro] iRhyiku:
Anyone else's Game Dashboard not work when rooted?

Trying to turn it on in settings just doesn't open the menu