yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] roirraW "edor" ehT:
Same here.

Edit: I confirmed it's working on my wife's P7P, which isn't even bootloader unlocked.

Edit 2: I wonder if something needs to be added to the DenyList for it to work. It's not Google Games - I tried that and rebooted.
[Google Pixel 7 Pro] iRhyiku:
Yeah it worked before I rooted my device, tried adding a bunch of services to DenyList but to no success :(
[Google Pixel 7 Pro] Lughnasadh:
Pixel 7 and 7 Pro Google Play System update appears but cannot be installed

Since launch, the Pixel 7 and 7 Pro have been running a Google Play system update from July, but some users are now prompted to install...

9to5google.com
[Google Pixel 7 Pro] roirraW "edor" ehT:
At least my Google Chrome sync issue appears to have stopped re-occurring after a few days. :)
[Google Pixel 7 Pro] collegencmc:
So I followed the process after doing a factor flash but get this when I apply: safetynet-fix-v2.3.1-MOD_2.0.zip

I didn't see this before, do I need make a change to something to enable it?

Good news is Adaway is working now. So thats a win.

Thanks!
[Google Pixel 7 Pro] madmuthertrucker:
In Magisk settings check zygisk and enforce denylist.
[Google Pixel 7 Pro] collegencmc:
OMG!!!!!!! Should have read the message sorry!!! Thank you for being nice about that. :D
[Google Pixel 7 Pro] madmuthertrucker:
No sweat. Somebody helped me get through it once too.
[Google Pixel 7 Pro] JakeDHS07:
Like he said we were all noobs at one point 😂
[Google Pixel 7 Pro] collegencmc:
So everything seems to be working but my Marriott app keeps seeing root, others that saw root don't see it anymore. Everything is enable and DenyList is configured. I even did hide Magisk. But it Marriott app still keeps seeing root. Any one have any other ides on what I need to add to DenyList to get Marriott to work?

Update: Well now CTS fails on safety check, it did work before that though.

Update 2: I just checked the my old phone (pixel 6 pro) and it fails to open Marriott because it sees root. So this not just a pixel 7 issue.
[Google Pixel 7 Pro] roirraW "edor" ehT:
If you added the Mariott app to the DenyList, then there is probably nothing else you can do. The only workaround if you can't get it to work is to use their website - although I don't know enough about them to know if that would sacrifice some features or convenience.

Also, after you add anything to the DenyList, you may have to reboot for it to take effect. It's even better to wipe the cache and data of any apps that you add to the DenyList, and then reboot. Did you wipe the data of the GMS as Displax's post says here?
[Google Pixel 7 Pro] dnsmo:
how do you find out what hardware version is your devices on?
[Google Pixel 7 Pro] Lughnasadh:
Settings>About Phone>Regulatory Labels
[Google Pixel 7 Pro] roirraW "edor" ehT:
Good question. I tried typing Hardware in the Android Settings search, and it looked promising listing "Hardware version" as an option, but when I clicked on it, it says:

MP1.0

which of course doesn't conform to what we know from Post #6 - Regarding P7P 5G model numbers and capabilities.

If you can achieve a mmWave connection, you definitely have a GE2AE. However, if you only achieve sub-6GHz, that doesn't necessarily mean you have a GP4BC - only that you might have one.
[Google Pixel 7 Pro] roirraW "edor" ehT:
New quote for Post #6. Thanks!
[Google Pixel 7 Pro] dnsmo:
thanks
[Google Pixel 7 Pro] Virus:
Haven't rooted anything in a while this made it a breeze ! Really appreciate all the effort in putting this together.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Happy to help! Cheers.
[Google Pixel 7 Pro] pndwal:
Folks, I may be missing something obvious; (I don't have P7 etc; never owned a pixel)...

But can someone give the technical reasons P7 can't support Magisk in boot.img?... It still exists right? And if ramdisk is in init_boot.img, it seems bootloader supports boot mode ramdisk at least... Or is the ramdisk type actually different?...

Of course Magisk will install basic ramdisk in boot.img where it's missing... This allows many A only legacy SAR devices (these report Ramdisk = No), especially Xiaomi, to support Magisk in boot mode; bootloader actually supports boot mode ramdisk even though OEM only supplies ramdisk in recovery...

More recently, with this compression method fix:

Support GKIs without ramdisk …

Fix #5819

topjohnwu committed on 12 May,

Magisk's manually added basic ramdisk in boot image w/ Magiskinit injected has been made to work instead of needing to patch vendor_boot ramdisk in Pixel 6 series devices (main ramdisk was moved here for GKI compatibility in A13 for p6 series) as other vendor ramdisks can now be merged with the new ramdisk in boot.img...

Please can someone say why it seems a similar manually added ramdisk in boot.img can't be made to work/host Magisk in Pixels launched w/ Android 13?

Thanks, PW
[Google Pixel 7 Pro] Lughnasadh:
I can't speak to your specific question but is it in regards to getting the OTA feature in Magisk working on this device? If so, there "may" be other barriers. According to vvb2060, to get that feature working again on Pixel devices would also require "implementing the partition digest calculation to overwrite the original value".

I haven't seen a PR submitted for this yet but haven't checked in the last few weeks or so and am also unaware if anything else has changed in the meantime that would affect this. I'm also presuming that this would affect the Pixel 7 series as well.

If this is not what you are alluding to, then please disregard.

Bootloop after OTA · Issue #5959 · topjohnwu/Magisk

Device: Pixel 6 Pro Android version: 12.1 (SQ3A.220605.009.B1) Magisk version name: cacf873 Magisk version code: 25001 The standard OTA process from the guide was followed, but it bootlooped. Here'...

github.com
[Google Pixel 7 Pro] roirraW "edor" ehT:
I'm sure this isn't enough, but it's something, at least. @Lughnasadh's previous post:

and @Namelesswonder's previous post:

Besides tagging @Freak07, I'm also tagging @edcsxz, @AndyYan, @anirudhgupta109, and @Namelesswonder for anyone's insight they may have on this.

Also added those four to the OP's thanks:

@edcsxz

@AndyYan

@anirudhgupta109

@Namelesswonder
[Google Pixel 7 Pro] roirraW "edor" ehT:
And thanks to @flar2 too. :)
[Google Pixel 7 Pro] pndwal:
Thanks for that link and comment by vv... It may be pertinent...

I was also aware that she reported Magisk compatibility w/ new A13 partitioning back in August in her Alpha release tg thread along with direction to manually patch init_boot.img citing this Google doc:

https://source.android.com/docs/core/architecture/bootloader/partitions/generic-boot

... And the Install to Inactive Slot function for preserving Magisk through OTAs is partly why I wondered about this... (Incidentally I believe this is now working fine for Pixels in general; that issue seems to be for P6 series in particular) 👍 PW
[Google Pixel 7 Pro] PurppleMonkey:
Hi !

I come back to you to share my experience:

For those who have read, I bricked my first Pixel 7. The problem is indeed mine

During the flash, the phone reboots in "fastboot d" mode to complete the installation. Except that, thinking that it wasn't normal, I turned it off at that moment... Inevitably, the phone ended up in the state by no longer working.

How did I find out?

On my 2nd pixel, I flashed the latest firmware with the official google flash tool which warned me that the phone was going to reboot in "fastboot d" mode... So... I understood that it was normal and that I had "**** in the glue" (French expression) the first time!

Thanks to @roirraW "edor" ehT for your help ! Maybe you could put this warning ?
[Google Pixel 7 Pro] pndwal:
So clearly @Lughnasadh was aware of the same info form vvb2060!... 😛

What made me wonder further is that my understanding is that similar to devices launching with Android 13 where the generic ramdisk is removed from the boot image and placed in a separate init_boot image to leave the boot image with only the GKI kernel, late A13 GKIs for Pixel 6 series also remove the generic ramdisk from the boot image and place it in vendor_boot image, and yet working main basic ramdisk with Magiskinit can be restored to boot.img in this case... PW
[Google Pixel 7 Pro] roirraW "edor" ehT:
I'm very glad you figured out what happened, and you're welcome again! I've thought about your suggestion, and at this time I think I will only keep this under advisement. The posts have so much information already, that I don't take lightly the thought of adding something like this. I've got a committee in my head and we voted no. 🤣

You shouldn't ever interrupt the factory image flash process, no matter which method you're using. If you feel strongly about the need for a specific warning, you can try to convince me, and I will try to keep an open mind.
[Google Pixel 7 Pro] Jon8RFC:
Some apps save locally that the device is rooted.

Go into the app info of android for the app in question, force stop, clear data.

Seconds-long video clip of what to do
[Google Pixel 7 Pro] Namelesswonder:
I've tested this several days ago and the Pixel 7 bootloader ignores the ramdisk in boot.img if you were to manually put one in.

The patch to the kernel that Magisk does to force load the ramdisk doesn't get applied for whatever reason, I've checked on a Magisk patched image and stock image, both kernels are the exact same. As far as I know this should be working because it's based on whether a kernel binary gets extracted when dumping the image you've selected to patch.
[Google Pixel 7 Pro] Lughnasadh:
You are welcome.

Yes, that is the same Google document I stumbled upon when doing some digging beforehand in anticipation of getting my Pixel 7 Pro that same day and realized (or at least ponder and asked) that we had to patch the init_boot instead of the boot.img with the Pixel 7 series. Then saw she had already confirmed that on her Alpha channel.

Yes, you are correct that the problems related to the OTA feature in Magisk only relate to the Pixel 6 series (and most likely 7 now). As you probably are aware of, John updated the bootctl , in January I believe, to bring back support for the OTA feature for Pixels in general, which had been dropped, I think about a year and a half earlier. But then several months ago people using the Pixel 6 series started having trouble with that feature again and that's when vvb2060 made that comment in Github.

Anecdotally speaking, it has been very rare that I have seen someone use that feature with success on the Pixel 6 series since then. I think I know of 2 people who reported success with that in the recent months. There may be more that I am not aware of but the threads (and TG channels) are full of people reporting problems with this feature.

Anyway, I digress...
[Google Pixel 7 Pro] Namelesswonder:
Interrupting flashing while in userspace fastboot shouldn't be deadly since it isn't capable of flashing critical partitions like the bootloader. But cutting it off could've caused anything wrong to happen while writing things to the NAND. Just takes one bit written to the wrong place to kill the bootloader on that slot.

At least you got a replacement.
[Google Pixel 7 Pro] hpower1:
thanks for this guide and to all that helped. Another pretty easy and straight forward process. Got mine rooted and going with no issues.

I ran my pixel 7 pro for a few days just to make sure. I had to give up on my pixel 6 pro. It constantly lost connection. I was just done with it. Was hoping this phone is better. I'm happy with it so far. I have not had one exclamation mark or drop/lost connection yet. Very happy with it, especially with all this support and quick root access.
[Google Pixel 7 Pro] roirraW "edor" ehT:
You're welcome! Glad you're having a better experience with the 7 Pro. Hope it continues.
[Google Pixel 7 Pro] hpower1:
Yeah me too! I was nervous using this the first time. After I got my sim in, I just went out and drove around, lol.

But so far so good. Kinda like some review videos have said, its what the 6 should have been. I was happy with that phone, just the cell service issues. This one is even better. I really like it.
[Google Pixel 7 Pro] michaelrager:
when I get to the command fastboot flash init-boot magisk_patched-25200_1a2B3c.img, I get

Sending 'init-boot' (8192 KB) OKAY [ 0.193s]

Writing 'init-boot' FAILED (remote: 'partition (init-boot) not found')

fastboot: error: Command failed

Does anyone know how to fix this error? I have tried many different things nothing is working.

HELP Please!!!!!!
[Google Pixel 7 Pro] roirraW "edor" ehT:
You downloaded the correct factory image? You extracted the "init_boot.img" from the inner zip, correct? Not the boot.img.

Are you using the very latest Platform Tools? Is this on Windows? Try a USB 2.0 port, and a different cable if available.

Edit: There is no "init-boot" partition. It's "init_boot". There's the problem. Should be an underscore, not dash.
[Google Pixel 7 Pro] roirraW "edor" ehT:
@michaelrager Make sure and see my edit above.
[Google Pixel 7 Pro] michaelrager:
Which particular one. I search and am not seeing it.
[Google Pixel 7 Pro] michaelrager:
OMG I see it is _ not -
[Google Pixel 7 Pro] michaelrager:
it worked thanks!!!
[Google Pixel 7 Pro] roirraW "edor" ehT:
You're welcome! Glad it was something easy. :)
[Google Pixel 7 Pro] J0nhy:
i'm on TD1A.220804.031, Oct 2022 already unlocked my bootloader but eevry time i tried this command "fastboot flash init_boot ***.img" it give me this error "FAILED (remote: 'failed to flash partition (init_boot_a)')" i also tried this one "fastboot flash boot magisk_pat***.img --slot all" this one doesn't give me any error but when i boot back to android magisk doesn't detect a patched boot, don't know what to do i've rooted many devices before including the pixel 6 pro and never had this issue before :C
[Google Pixel 7 Pro] roirraW "edor" ehT:
First, is the .img that you're trying to flash to the init_boot partition, the init_boot.img or the boot.img? i.e. Did you extract the init_boot.img out of the inner zip of the .031 factory image zip?

Also, you shouldn't be patching the boot.img at all. Please re-read the instructions in Post #2 starting at step #7 "Extract only the init_boot.img file from the image-cheetah-etcetera.zip to the same platform-tools folder."

The only .img file you should be patching with Magisk and flashing is the init_boot.img. This is the only difference between rooting the Pixel 7 Pro and the 6 Pro, which I had too. No need to extract the boot.img, patch it, or flash it.

Lastly, are you using the very latest Platform Tools and drivers - covered in step #2 "Always use the latest ADB/Fastboot (SDK Platform Tools) and Windows USB Drivers."
[Google Pixel 7 Pro] i5lee8bit:
Finally started trying to catch up with this thread, but stopping here to reply lol. Gotta get the kiddo ready for bedtime soon, so I'll try to catch up (and maybe post a proper update to my weird issue too) later, hopefully sooner than later. 😉

So yeah, after everything seeming fine for the longest it ever had, the problem came back again. Sad face. But then something weird happened this morning. Chrome actually prompted me to set up sync, right from the new tab page. The proper way! And went without a hitch! I wanted to check and see if the general issue was truly fixed, so I force killed Chrome and it was still sync'ed when I opened it! And the other things (Tips & support / GPay) were now working, and continued to work, too!

Unfortunately it didn't last long lol. I rebooted as a final test, and it was back to the usual brokenness. And Chrome hasn't prompted me again to sync as of yet, Tips & support still crashes Google Support Services, and GPay doesn't finish loading. So weird!

I even checked if Google Play system update finally went through (negatory - still July 2022) even curious if maybe the seemingly widespread issue of it not installing for us P7 users was responsible, or maybe even a Chrome or WebView play store update. Again, false. So none of those things seemed to point to the temporary fixing of the problem this morning. ¯\_(ツ)_/¯

So now I'm wondering if I'm just in some kind of 1% of 1% experiencing an issue like this and it will indeed eventually just fix itself. As for my phone exchange, I'm still glad I'm doing it. Before contacting Google, my thought was that maybe I should wait til November update drops and see if it fixes it. But that would be after my return date, so as far as I'm concerned I'm way better off at least ruling out that I have a defective phone. As an added bonus, they were "having issues with their replacement system", so they instead had me place a new order and set up the return for me - but made it so I will keep the preorder credit! So I was literally able to use the $200 credit on the Pixel 7 Pro itself! Sweeeeeet!! 😀😀😀

But yeah, what you said makes me further wonder if it may eventually "settle" on its own through future updates or whatever. At least I'll have both devices side by side for a little while before I have to return it which might help further testing.
[Google Pixel 7 Pro] hpower1:
strange, a new one for me. initially, my garmin watch connected fine. Now, after rooting, I can't get it to connect. Anyone ever experience that?

edit: never mind. I got it. Apparently after enough reboots and trying again it worked. If anyone has issues keep trying it. In the middle of all that I did do a reset of all network/bluetooth settings. Didn't work right away but after a bit I got it.
[Google Pixel 7 Pro] J0nhy:
Lol thank you so much, i was doing boot.img all this time xD
[Google Pixel 7 Pro] roirraW "edor" ehT:
Thanks for another update. Sorry to hear you've currently still got the trouble. I forget if I already told you, my own different sync issue stopped happening and all has been fine for at least a good 3-4 days now.

Glad you got further advantage to order your new P7P.

Cheers!

You're welcome! Once again, I'm glad it was something simple.
[Google Pixel 7 Pro] rlewis312010:
Does anyone know how I can safely check to see if slot B is bootable for me? Like, to see if it has a working bootloader? I read a horror story about someone switching to slot B and getting stuck (like with TWRP).
[Google Pixel 7 Pro] roirraW "edor" ehT:
The easy solution would be to go ahead and flash the bootloader to the other slot, switch slots, fastboot reboot bootloader, and then flash-all.bat with the -w taken out of the batch file.

Whether you root or leave the second slot unrooted, is up to you. Then you can switch slots back to your original if you want.
[Google Pixel 7 Pro] rlewis312010:
Yeah thanks but that's all beyond me.
[Google Pixel 7 Pro] jucin:
This is my first Pixel Smartphone and currently its the Most difficulr phone to root it and unlock the bootloader. I rooted before only Phones like Samsung and oneplus. I am wondering If there will be a easier way to root the pixel 7 pro
[Google Pixel 7 Pro] eg1122:
Detailed instructions are all on the OP, but I'll give you the quick and dirty (no details).

1. Unlock bootloader

2. Check what build you are on

3. Download said build from Google

4. Extract init_boot.img from zip.

5. Patch the init_boot.img

6. Flash patched init_boot.img

ex. fastboot flash init_boot nameoffile.img

7. Reboot

If more details are required check OP
[Google Pixel 7 Pro] roirraW "edor" ehT:
I don't consider it difficult at all, and I've been rooting for over 12 years. I definitely prefer this to how I have to root updates on my Samsung Galaxy Tab S8 Ultra: using unofficial sources for software to find, download, extract, and flash updates, having to copy the entire large AP image to the device, root it, then copy it back... One time apparently it became corrupted and I didn't know until I flashed it and had to factory reset the tablet. Now I check the MD5 hash on each device after a copy, plus I test the .tar with 7-Zip after copying it back to the computer.

For the Pixel, it just takes getting used to and uses official sources of all required files. Before you know it, it'll seem like nothing to you. And unlocking the bootloader and rooting doesn't void your warranty as with Samsung, or permanently gimp your device like Sony. No, there won't be a different way to root.
[Google Pixel 7 Pro] Ghisy:
I'm wondering how far along is Freak07 with his Kirisakura kernel for the P7P... :P
[Google Pixel 7 Pro] pndwal:
Many thanks for reporting this analysis!...

Ah!... This clue has helped me to retrace documentation + my assumptions and understand key differences now... But I'm wondering if it's actually dependant on kernel binary... is the kernel actually patched or should this be 'based on whether original init binary gets extracted when dumping the image you've selected to patch'... Magisk documentation states:

For devices launching with Android 13, this init is removed from the boot image and placed in the separate init_boot image along with generic ramdisk leaving the boot image with only the GKI kernel.

... I now believe that this is why we can't patch boot.img... bootloader is already finding a boot type ramdisk in init_boot.img...

Conversely, for devices upgraded to Android 13 that continue to use Android 12 or older kernel versions, the original init along with generic ramdisk remain where they were leaving the Generic Kernel Image (generic boot image) with both first stage init and the GKI kernel.

It seems that this is why we can patch boot at this point...

https://source.android.com/docs/core/architecture/bootloader/partitions/generic-boot

The title for this fix:

Support GKIs without ramdisk

threw me off as it seemed ramdisk was moved out of GKI image (boot.img) in A13 for p6 series'... Actually generic ramdisk is apparently still there and only vendor_boot ramdisk parts were moved out... So patching boot (hosts GKI) works it seems because it's init is available for patching...

Since this boot.img is NOT actually (at least entirely) "without ramdisk", I believe the fix title is misleading... I'm not sure, but I doubt there is any need to "create the CPIO from scratch" per issue comments; Magisk already does that where needed anyway, not this fix, so seems this fix is reall "Support GKIs by unifying compression algorithm" and simply fixes existing ramdisk compatibility for merging vendor ramdisks rather than manually adding ramdisk / creating from scratch...

I may be way off here and there may be cases where generic ramdisk / init is absent in boot image for devices updating to A13; if so I'm not seeing where init has been put...

Further, I suspect that Magisk may use presence of backup init to indicate Ramdisk = Yes so Ramdisk = No might indicate for sure if CPIO was 'created from scratch')...

Anyway clearly early GKI boot.img Magisk compatibility doesn't mean that this will work going forward w/ SDK 33+ architecture changing to kernel-only boot images... It just seemed then that patching boot.img was the more elegant solution...

I guess we'll see Magisk adapt to Google's new template... Patching ramdisk outside GKI shouldn't pose any real obstacle to finding a proper fix for OTA updates supporting Magisk preservation etc anyway... 🙃 PW