yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] phoinix_gr:
Still holding on Aug Update based on what I read here.

Can someone confirm if SafetyNet is passing (at least basic and device) with either:

- safetynet-fix-v2.4.0-MOD_1.3-Zygisk.zip

- safetynet-fix-v2.4.0-MOD_2.0-Zygisk.zip

?

Only interested in google wallet being operational.
[Google Pixel 7 Pro] supermansaga:
It doesn't seem like device is needed for wallet. Or the failure doesn't really feel real. I am P7P and have Aug update.
[Google Pixel 7 Pro] roirraW "edor" ehT:
On the August update, Mod 1.3 works exactly like it always did (Basic and Device). Mod 2.0 is definitely not working well anymore. I hardly touch Google Wallet, so I can't specifically address that part. :)
[Google Pixel 7 Pro] madmuthertrucker:
I'm failing device integrity and strong integrity, but passing basic. On safetynet-fix-v2.4.0-MOD_2.0-Zygisk.zip. On July update still, but everything is still working. Wallet and all my banking apps are working fine. I was going to update and considering going back to 1.3.
[Google Pixel 7 Pro] Lughnasadh:
Due to the changes Google recently made, people with a Pixel 7 series device should use Displax's 1.3 mod to pass both basic and device integrity until he updates the mod (which he is currently working on). Pixel 6 series users should still be able to pass both using Displax's 2.0 mod.

Google also patched Strong integrity passing, so neither version will allow you to pass that now. People shouldn't need to pass that anyway.
[Google Pixel 7 Pro] simplepinoi177:
I think it's fairly ironic that Google is working so diligently on "patching" exploits to pass Strong Integrity when rooted, and yet have been desperately dropping the ball on "patching" platform-tools -- especially considering the latter literally bricks devices (some irreparably).

I acknowledge that it's probably two different, separate divisions, but still.....for me it just highlights the frustrating circumstance...............
[Google Pixel 7 Pro] synesthete:
Google Wallet is working for me on the August update using latest magisk canary and safetynet-fix-v2.4.0-MOD_1.3-Zygisk.zip. To get it working, I go into airplane mode and then force stop and clear data for Play store, Google Play Services, Google Wallet, pay, Google One and then flash the safetynet mod, reboot and then turn off airplane mode. Then I open wallet and add the card.
[Google Pixel 7 Pro] K1nsey6:
Im on 1.2 and everything working perfectly
[Google Pixel 7 Pro] phoinix_gr:
To provide an update.

Just pushed the Aug Update.

Passing basic and device Integrity for SafetyNet. Everything seems to be working as expected.
[Google Pixel 7 Pro] GrndSers-Rcng:
Hello, hopefully someone can help me with this issue.

I have a Google P7P running latest A14 and using Magisk Canary. When my phone is rooted with Magisk and I'm playing a video, or in the YTM app playing music, or with the camera app open, or Chrome open (this is just a few of the situations my issue happens), and I rotate my phone either portrait to landscape or vice versa, the phone struggles to rotate and for example if I'm in the camera app, the shutter button will gray out, or the YTM app will stop playing and forget what song it was playing, or the video that is playing will stop playing or take forever to play, or chrome will close and then minimize the whole app to PiP mode. Literally apps opened when rotating the screen will act super weird and stop working.

I never had this issue with A13 while rooted and I have tried Magisk Stable, also using Magisk with no modules, factory resetting and rooting right after the reset without any apps installed, etc, but regardless this issue happens in A14 while the phone is rooted with Magisk.

I have searched all over the place to see if this is happening to anyone else, but haven't seen it mentioned anywhere else. Just wondering if it's just me and if there is something I can do to fix it. Any help you guys can provided would be super appreciated
[Google Pixel 7 Pro] roirraW "edor" ehT:
@GrndSers-Rcng, I'm not using the Beta version of Android, but you might want to copy/paste your post to the 14 Beta thread in case anyone there thinks of anything, although I can't think of anything to try that you haven't already.

https://xdaforums.com/t/august-10-2...upside-down-cake-pixel-7-pro-cheetah.4550933/
[Google Pixel 7 Pro] pndwal:
Just out of curiosity, can anyone say why temp boot, fastboot boot init_boot.img won't work on this device?... Wondering if it won't work on other LV A13 (API/SDK 33) devices... 🤔 PW
[Google Pixel 7 Pro] Lughnasadh:
See below for previous discussions about this topic...

Keep in mind these discussions took place about 1 day after the phone was released.

https://xdaforums.com/t/august-7-20...7-pro-cheetah-safetynet.4502805/post-87569005

https://xdaforums.com/t/august-7-20...7-pro-cheetah-safetynet.4502805/post-87566669

https://xdaforums.com/t/august-7-20...7-pro-cheetah-safetynet.4502805/post-87570539

https://xdaforums.com/t/august-7-20...7-pro-cheetah-safetynet.4502805/post-87570833
[Google Pixel 7 Pro] Golf c:
I can attest. It's still not working right but still flashes the factory image successfully.

It now has been flashing 20-21 super partition images???

Explain in 4 year old English to the Boomer please?
[Google Pixel 7 Pro] bird333:
What's not working right 34.0.4 platform tools?
[Google Pixel 7 Pro] pndwal:
I guessed user meant fastboot boot init_boot.img won't work but fastboot flash init_boot init_boot.img does... Don't know why images in super were mentioned... Let's see... 🙃 PW

Guess not...
[Google Pixel 7 Pro] Lughnasadh:
The change you are seeing is due to everything being flashed in fastboot now rather than in fastboot and fastbootd. It now skips fastbootd when using flash-all. Because of this it's also a little faster. This was implemented in 34.0.0.

Improved flashing: flashall will now skip reboots to userspace if it can.

EDIT: One word about 34.0.4. It may have problems with wiping when using flash-all. Seen at least one report that user left the -w intact but it still didn't wipe. A few others reported this same behavior in other, previous version of 34+.
[Google Pixel 7 Pro] Ghisy:
I'm sticking to 33.0.3 until further notice. It's been fine, even for flashing Android 14 beta 5 on my (unused) Pixel 6 Pro.

Speaking of 14, I guess we're not gonna get the stable version until September, huh? 🤔
[Google Pixel 7 Pro] Lughnasadh:
Think he meant the changes he saw in the way Platform Tools 34+ uses flash-all. See my post above.
[Google Pixel 7 Pro] bird333:
I have a question about 'adb' sideloading a rom and disabling the verity & verification flags. Does sideloading the rom after flashing vbmeta with flags disabled overwrite vbmeta? I.e. making it as if you didn't disable the flags. Basically should you flash vbmeta after you sideload the rom on an update or does the order not matter?
[Google Pixel 7 Pro] roirraW "edor" ehT:
I don't know the answer, but just know that it never hurts to disable Verity and Verification at any time, except the first time you do so (or if you boot with it enabled, then disable them again later) when you need to wipe, of course.

Hopefully, someone can tell you precisely what you're asking, though.
[Google Pixel 7 Pro] Lughnasadh:
Sideloading should flash the stock vbmeta.img, which means those 2 flags will be enabled once you reboot. Therefore, you should disable those flags after you sideload but before you reboot.
[Google Pixel 7 Pro] badabing2003:
@bird333

What @Lughnasadh says.

Here's an example command sequence

adb.exe reboot sideload
adb.exe sideload "ota-zipfile.zip"
adb.exe reboot bootloader
fastboot.exe --disable-verity --disable-verification --verbose flash vbmeta vbmeta.img
# optional flash patched boot / init_boot
fastboot.exe reboot
[Google Pixel 7 Pro] bird333:
See that's what I thought, but when I installed Evox I did the vbmeta flash first and then did the rom sideload and vbmeta flags were still disabled. Checked with PF. Doesn't make sense to me. Could it be because sideloading a rom from recovery the phone seems to be in 'adb' mode and not bootloader and maybe adb doesn't flash those files even though they are in the zip file? That would explain why the Evox instructions tell you to flash several files from bootloader before you sideload the rom even though those files are inside the rom.
[Google Pixel 7 Pro] badabing2003:
You have to unpack what you flashed and see if there is vbmeta in it, if there isn't, it doesn't matter if you do before, after or not at all.

I suspect probably what you flashed did not include vbmeta.
[Google Pixel 7 Pro] bird333:
No it did. That's where I got the vbmeta file from. Which doesn't make sense unless 'sideload' doesn't copy those files for some reason. Another possibility I guess is that once you set the 'disable flags' with the first vbmeta flash, they stick no matter how many times you flash 'vbmeta' until you finally boot the rom.
[Google Pixel 7 Pro] simplepinoi177:
Spoiler content hidden.

So calling @badabing2003, if you could give an assist answer a couple of questions...

I'm finally getting around to flashing August's update. I've only ever flashed Full Factory images to update before (since Pixel 2 XL). As you've pointed out in the posts I've quoted, there is a solid benefit from flashing the OTA to both slots -- making both slots directly bootable & accessible if something happens to one slot.

Questions...

Do I have to confirm/make-sure of anything before getting started. I imagine both slots have to be on the same bootloader version or something? Anything else to look out for?

I'm sure it's covered somewhere, but as it's not covered here in this guide and I've only ever flashed Full Factory's -- I can't patch the image (presumably the init_boot.img; if it resides in there at all) in the OTA image file, correct?

Is it better to apply the OTA from recovery, or from after running the command adb reboot sideload? or are they both the same?

I was thinking I would manually have to switch slots to flash/sideload the OTA update to both, but if I'm reading correctly that's unnecessary because the protocol for OTA update is already to switch to the other slot anyways, correct? I simply just go about sideloading the OTA twice, one after the other?

I appreciate any help & clarification on this -- from you or any other member who replies to this. Thanks in advance!
[Google Pixel 7 Pro] bird333:
I'm sure badabing2003 will be along but I did this with PF. I can't answer all your questions, but you don't have to manually switch slots. You just basically flash the full OTA twice. The software will automatically switch slots.
[Google Pixel 7 Pro] badabing2003:
Deleted

UPDATE:

I'm sorry I gave you PF instructions, didn't realize you wanted manual instructions.

Just follow what @V0latyle says.
[Google Pixel 7 Pro] V0latyle:
You can only use an OTA equal to or newer than what is already installed

You can, you just have to use Payload Dumper to get it. Pixel Flasher can also process the OTA to get it

They're the same. Install from SD card obviously requires the package to be in storage. Apply update from ADB serves it from your PC

Correct, no need to switch slots. Installing the OTA will always switch to the other slot.

If you want to make sure, boot to bootloader and run fastboot getvar current-slot

You bet buddy
[Google Pixel 7 Pro] avid_droid:
Wait what? I can root now on Verizon?
[Google Pixel 7 Pro] TotallyAnxious:
No you can't. Just sometimes there are carrier additions sent to Google after a deadline so it gets its own firmware. So that's just an img for that firmware.
[Google Pixel 7 Pro] avid_droid:
Thanks. Haven't been here in awhile and seen that and was like,"oh wow!" But guess not.
[Google Pixel 7 Pro] simplepinoi177:
Thank you all for the help and the quick response!

My apologies for the confusion; I know about your tool, but I like getting hands on to understand all aspects as well as I can that I try to do things manually. It's just that I didn't come across the benefit of OTA updating to both slots until you were speaking about it; so I just decided to ask you directly. I had in mind asking you in the Pixel 7 Pro PixelFlasher thread, but I figure that might be confusing and/or a bit of hijacking the thread to not being directly related; i.e. everyone in there saying "just use the tool" or "the tool does all that for you".

Thanks for confirming my assumptions and addressing my questions & concerns. I just wanna make sure I do this right. After reviewing my own list of steps for monthly updates, it will be a bit of a relief that I don't have to keep double-checking that I removed the "-w" each and every time. I don't think I want to learn using a "Payload Dumper" that I'll just download the Full Factory image -- especially considering I already know how to do that. It's just about the downloading time, bandwidth, and storage space. I guess it is rather helpful that @reaper000 provides an already patched one if I wanted to skip that; although, again, I like being hands on that I'll do/make my own.

Another (hopefully last) question; after sideloading/applying the update and it finishes, can I just run the command adb reboot sideload once again and immediately sideload once more (so it applies to the other slot) -- as it seems after sideloading it doesn't reboot automatically and stays in recovery -- or should I load up the OS in between?

Also I'll input @badabing2003 's post below because it probably needs to be repeated; for those interested in what I'm doing and/or wishing to accomplish it without the use of a computer...
[Google Pixel 7 Pro] badabing2003:
No don't do it, you want to make sure that you can boot properly to the newly flashed system before overwriting the good one too.

When you boot to system, wait for Android to finish the setup (optimizing the apps)

And then repeat the OTA
[Google Pixel 7 Pro] V0latyle:
The boot image would be no different, the only thing that occasionally is, is the radio image. Otherwise there is no software difference between Google and carrier specific firmware releases, to my knowledge
[Google Pixel 7 Pro] roirraW "edor" ehT:
Android's Nearby Share is becoming as seamless as AirDrop

Sending files with Nearby Share is already fast, but this change will make it even faster

www.androidpolice.com
[Google Pixel 7 Pro] V0latyle:
FINALLY, I can now send pictures of my hairy belly button to all the unfortunate sods around me
[Google Pixel 7 Pro] TotallyAnxious:
I've always wondered if you're an innie or an outie.
[Google Pixel 7 Pro] roirraW "edor" ehT:
To clarify further, it's for those who are using their factory carrier unlocked Pixel 7 Pro who unlocked their bootloader, so they can root, but are using it on the Verizon network, so it's normally better for them to be on the Verizon firmware.

I just compared the TQ3A.230805.001 Global and TQ3A.230805.001.A2 Verizon init_boot.img (to init_boot.img) and boot.img (to boot.img) files, and they all have different SHA-256 hashes, so there's some kind of difference - the meaningfulness or not of the differences can't be speculated without more information, though.
[Google Pixel 7 Pro] V0latyle:
Would be interesting to decompile them and compare differences but that's way out of my wheelhouse, I'm just a dumb grunt
[Google Pixel 7 Pro] roirraW "edor" ehT:
Me, too! Someone accessible to all of us, either here or elsewhere, probably already knows the differences - but I don't know who specifically would be the best person to ask. I wonder if @Freak07, @DespairFactor, or @tbalden know. There are probably others who it would be good to ask, as well.
[Google Pixel 7 Pro] DespairFactor:
It's likely because the SHA is generated as part of the build and these images are generated by Google per image. Which means all images can be the same but since the image was built at a different time it could have a different SHA.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Makes perfect sense to me. Thanks!
[Google Pixel 7 Pro] badabing2003:
Any change in the code will cause a checksum change.

And for sure build.prop between different images will be different.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Thanks @badabing2003!

Google Contacts now shows local time and weather

Google Contacts has seen an uptick in new features this year, and it continues today with local time and weather information...

9to5google.com

Interesting...
[Google Pixel 7 Pro] thereason00:
Just wanted to say thanks man, literally nothing I've tried for like the last 9 months has worked in getting cards added to Google Wallet until I followed this exactly. THANK YOU.

Haven't actually tried to use Wallet to pay anywhere where yet, but this is further than I've gotten in a long long time.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Woohoo!
[Google Pixel 7 Pro] supermansaga:
Have you guys seen this? The good days are over soon?.

Google's New Feature Ensures Your Pixel Phone Hasn't Been Hacked. Here’s How It Works

Pixel Binary Transparency is the latest security benefit for Pixel owners.

www.wired.com
[Google Pixel 7 Pro] simplepinoi177:
I don't know; after reading the article, it seems to me that it is a protection to compare the phone's integrity from factory to in hand of the consumer.

Google has always been rather open & amenable to the custom ROM, kernel, & rooting scene/development -- coming from the Nexus to every single Pixel. It's why many (if not most) suggest Pixels for those who want to be able to for sure unlock the bootloader with minimal issues & requirements/steps as well as other outside of stock modifications. If that's historically been their stance and and outlook on it, I doubt they'd change things up now.

I'd put it how they keep plugging holes for SafetyNet/Play Integrity API type of security verification, but they wouldn't lock things down that they wouldn't allow/block anything outside of stock ROM/unlocked bootloader/root access.
[Google Pixel 7 Pro] roirraW "edor" ehT:
I think every year, one or two things Google does cause some to wonder the same thing, but I take everything at face value, and unless they say "you'll no longer be able to unlock the bootloader" (which would affect their beta testing) or "you'll no longer be able to root your phone", I think it's just always up to the talented developers of Magisk and all root modifications to work around Google's latest security measures.
[Google Pixel 7 Pro] roirraW "edor" ehT:
I'm still not enthused about potentially being forced to use eSIMs in the future, as this ease-of-transfer feature doesn't account for if a phone with an eSIM just stops working, since you have to start the transfer process on the existing phone. I'd rather avoid having to deal with the carrier in such a circumstance, unless there's also a possibility to transfer eSIMs on their website, although I doubt if my pre-pay account would implement such a feature as quickly as a regular account.

This is how Android’s eSIM transfer feature will work

The process of transferring eSIMs from your old Android phone to a new one is about to get a lot easier.

www.xda-developers.com
[Google Pixel 7 Pro] supermansaga:
For prepay account, one just has to call customer service to unbind their esim from the old device to the new device. It is a pain in the ass, but it gets the job done. I recall that is how I got my T-Mobile to work. Probably up till March or April update, I had to call them, because each update treated the same phone as a new device. But no more. Just cant remember exactly which update
[Google Pixel 7 Pro] Ghisy:
Honestly, I'd rather avoid eSIMs as long as I can.

Whenever I travel to Japan, I buy a local SIM card for my trip. If I need to insert my home SIM in my phone, it only takes a few minutes. Same to switch back. What happens if both are eSIMs? What if there's a problem with activation? Too many points of failure and annoyances IMO.
[Google Pixel 7 Pro] halfbytecode:
I just wanted to update in this regard that the method I described earlier to install OTA updates, while being rooted, works.

I tried it with a custom ROM, which also has incremental/delta OTA updates.

Upon seeing an OTA update being available, I first restored the unpatched init_boot.img using Kernel Flasher, which as suggested earlier can also be done using Magisk -> Uninstall -> Restore Images option, if Magisk has backups, which it does in most cases. It does unless you installed Magisk by manually patching the init_boot and flashing it, and did not yet install an OTA update after that.

Followed by restoring the unpatched init_boot, I installed the OTA update, but did not reboot.

Following this, I installed Magisk to the other slot using the Magisk app.

Then I finally rebooted the device, and it booted back with OTA update installed and rooted.

This should also work on stock ROM, if you are able to get OTA updates to show up while being rooted.
[Google Pixel 7 Pro] UberNorse:
Has anyone updated to Magisk Beta 26.2 on the Pro? My wife just got the Pixel 7a and I rooted hers with 26.2 and she has all the same modules as me but I'm afraid to update to the Beta on the Pro just in case. I have it set to upgrade stable channel but I thought about going forth with Beta. Thoughts?
[Google Pixel 7 Pro] GuyInDogSuit:
If the stable build is working fine, then there's not really any benefit to switching to beta unless a Pixel update breaks Magisk.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Besides what @GuyInDogSuit said, the 26.2 Beta will likely become 26.2 Stable when it's ready. Might as well wait until it's thoroughly tested by others before upgrading it.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Google's Pixel 8 and Watch 2 launch event set for October 4

Google's started sending out invites for its Pixel event, set to take place in October.

www.xda-developers.com

10 AM Eastern Timezone

No, I don't yet know if I'll go for the 8 Pro, but it's a possibility.
[Google Pixel 7 Pro] Ghisy:
DO.NOT.TEMPT.ME
[Google Pixel 7 Pro] supermansaga:
It has to be rootable and give me a good trade in price for 7 pro
[Google Pixel 7 Pro] LLStarks:
If you have a trade-in, T-Mobile's new next plan should allow you to get the pixel 8 pro for $120 over the course of a year with zero down. And then at the end of that year, you can trade that phone in and get the pixel 9 pro for also $120 over a year and zero down.

And assuming you are a good T-Mobile customer, they will unlock if you ask nicely.
[Google Pixel 7 Pro] supermansaga:
Sources: Pixel 8 Pro will keep physical SIM card and add Night Sight for video

The Pixel 8 series will keep the physical SIM card tray in place, while the Pro will add Night Sight video. Despite recent rampant...

9to5google.com

Physical sim will be here!! If it's rootable, then I guess I will trade in my P7P.
[Google Pixel 7 Pro] LLStarks:
Unless you get the Verizon variant, it'll be rootable. Likely just need Magisk and Play Integrity Fix.
[Google Pixel 7 Pro] Ghisy:
Why wouldn't it be rootable? If bought straight from Google or unlocked, I don't think it will be a problem!
[Google Pixel 7 Pro] Samuel Holland:
No doubt, this sounds way nicer than the 1100+.
[Google Pixel 7 Pro] simplepinoi177:
It looks like (as is expected? I don't follow beta releases, but supposedly there's not usually a release after QPR beta 4 or 5, so the next one has to be stable right?) the upcoming monthly update is going to be the release of Android 14 stable! Apparently, going off of the "leaked" next firmware build number, it seems that it's set/scheduled for release on the 5th ("230905") -- barring any hiccups or unexpected reasons to postpone...

source

https://twitter.com/i/web/status/1697627492826112343
[Google Pixel 7 Pro] roirraW "edor" ehT:
There's nothing in the rules that says there's no possible way they'll have a Beta 5.3, or Beta 6, even - but I'd say there's more than 75% chance that the next release will be Stable 14.

Edit: I think the date in the firmware is unrelated to when it's actually released. The current Stable firmware is 0805, but it came out on the 4th (first Monday).