GPay/Wallet doesn't work on the Global build either. I guess I'll save myself the hassle of re-imaging my phone to the T-Mo build and will go back to using my debit card for now.
How To Guide March 13, 2023 TQ2A.230305.008.C1 Global | .A3 WINDTRE/Canada - Unlock bootloader / Root Pixel 7 Pro [Cheetah] / SafetyNet
- Thread starter roirraW "edor" ehT
- Start date
-
- Tags
- bootloader pixel 7 pixel 7 pro root
Successfully call the bank and activated Google wallet and seems that fine now but will see in market today is it work. What bother me is bad quality call when I speaking with someone and no Volte . My provider support 5G and activated e-sim but seems not work without root and enable it without application. Will see
No, I haven't had any reason to. The normal USNF and deny list, plus setting up the app while unrooted and then re-rooting, works well enough. All my other apps including banking apps work fine solely with USNF and deny list.
EtherealRemnant
Senior Member
Staged rollout. Download the full OTA image and flash it yourself with adb sideload.
Full OTA Images for Nexus and Pixel Devices | Google Play services | Google Developers
developers.google.com
so wallet and safety net (integrity check or whatever it's called now) is broken on february update? I saw one comment on the previous page that battery drain is awful. Any other comments? Novemeber battery was soooooo good. I wish we could just have that back. Others have said the same thing, so it seems there is something behind this observation.
Seems like the most recent update of Google Wallet flags as rooted phone. I downloaded the January 13 version of Google Pay and i can use my bank card normally with Magisk
Safetynet passes on my phone with Feb update and Magisk 25.2.
Google Wallet, my banking and corp apps also run fine and dont detect root.
I have Magisk hidden, Shamiko .6 installed and USFN 2.4 installed.
Last edited:
Same here with Magisk hide, USFN 2.40 and deny list.
The question was
Why is there no notification that there is an update!?
That the phone can be reflashed manually and so it is clear
EtherealRemnant
Senior Member
I just told you why. It's a staged rollout. Not everyone gets it at the same time. It puts less strain on the servers and giving the update to a small amount of people at each interval makes it easier to deal with if the update is broken and has to be pulled.
When you say "denylist" you just mean you're enforcing denylist, right? So some people need to use shamiko and extra stuff while others don't?
Is the wallet detecting root a wallet all update or part of the February update?
GPay and Wallet both open with no problem and GPay worked fine at 7-11 this evening.
Maybe a stupid question:
I purchased the device from Telstra, but I haven't updated the firmware since November and now I can see there is a specific Telstra version. I'm not sure what the difference is. Any idea anyone? I also want to know if it would work if I flash the universal image on this device, not the Telstra-specific one. Would I have to do some extra/different steps?
Thanks in advance to anyone that puts in the effort to answer a noob.
I purchased the device from Telstra, but I haven't updated the firmware since November and now I can see there is a specific Telstra version. I'm not sure what the difference is. Any idea anyone? I also want to know if it would work if I flash the universal image on this device, not the Telstra-specific one. Would I have to do some extra/different steps?
Thanks in advance to anyone that puts in the effort to answer a noob.
I'm not sure about going from Telstra to Univeral on Pixels. Used to do that normally on OnePlus (EU to Global and vice versa). My P7P - also in AU - is unlocked and not carrier-linked.
Does your build have specific Telstra mention in the name? If so, I would assume safety and go ahead with the Telstra build. Or alternatively, you can let the device update noramlly if you're not rooted.
Hope the more Pixel-experienced members here can assist you further.
P.S.: I LOVE how you're been on here since 2008 and this is your first post!
I'm not sure about going from Telstra to Univeral on Pixels. Used to do that normally on OnePlus (EU to Global and vice versa). My P7P - also in AU - is unlocked and not carrier-linked.
Does your build have specific Telstra mention in the name? If so, I would assume safety and go ahead with the Telstra build. Or alternatively, you can let the device update noramlly if you're not rooted.
Hope the more Pixel-experienced members here can assist you further.
P.S.: I LOVE how you're been on here since 2008 and this is your first post!
Thanks for the quick reply Fishawy! Doesn't say anything about Telstra in the build name or anywhere in Settings apart from the SIM info, but I rooted it on the day it came, so no updates for me
I'll wait for someone more Pixel-experienced to chime in... just in case P.S.: That year only shows when the forum needed an account to download an attachment..... I wasn't even a developer back then... I've been here forever, just never had a question that wasn't answered. That speaks well about my search skills I reckon
Indeed it does! 14 years no questions, amazingThanks for the quick reply Fishawy! Doesn't say anything about Telstra in the build name or anywhere in Settings apart from the SIM info, but I rooted it on the day it came, so no updates for me
P.S.: That year only shows when the forum needed an account to download an attachment..... I wasn't even a developer back then... I've been here forever, just never had a question that wasn't answered. That speaks well about my search skills I reckon
If no Telstra, then I would use the Global build, but that's just me. You should wait for others to confirm though.
You also might wanna take a look at the Pixel Flasher tool, which can be found in a separate thread on this forum. Makes flashing a lot easier with less room for error, which is handy for a Pixel-beginner like myself.
Attachments
EDIT: Seems that I'm not alone:
forum.xda-developers.com
Hi all,
for me it is the same. Update via PixelFlasher and root directly with it. SO smoothless!!
But now Google Wallet is not working again, also Netflix is not viewable in Play Store. (Both are hints that there are problems with SafetyNet.
Checked with YASNAC App:
Model
Pixel 7
Android version
13 (API33)
Security Patch Level:
2023-02-05
Google Play Services version
23.03.13 (190400-503260631)
Result
Basic integrity
Pass
CTS profile match
Fail!
Evaluation type
BASIC
Magisk App is hidden and Denylist ON
MAGISK MODULE ❯ Universal SafetyNet Fix 2.4.0
Universal SafetyNet Fix Magisk module Magisk module to work around Google's SafetyNet attestation. This module works around hardware attestation and recent updates to SafetyNet CTS profile checks. You must already be able to pass basic CTS...
forum.xda-developers.com
Hi all,
for me it is the same. Update via PixelFlasher and root directly with it. SO smoothless!!
But now Google Wallet is not working again, also Netflix is not viewable in Play Store. (Both are hints that there are problems with SafetyNet.
Checked with YASNAC App:
Model
Pixel 7
Android version
13 (API33)
Security Patch Level:
2023-02-05
Google Play Services version
23.03.13 (190400-503260631)
Result
Basic integrity
Pass
CTS profile match
Fail!
Evaluation type
BASIC
Magisk App is hidden and Denylist ON
Last edited:
Top Liked Posts
-
3
Do you mean this is a Flash-All.bat for the Graphene OS?
My stock Android Flash-All.Bat looks like this after removing the-w:
Hence, the confusion, if we're talking about something other than Google's official firmware.Code:fastboot update image-cheetah-tq2a.230305.008.c1.zip2
yes, removal of any (although normally there is just 1 instance) instance of "-w" works best; just keep in mind spacing before and/or after...so the line looks good
Also I'm curious as to why you added "--skip-reboot"?
I've only ever experienced adding that command for when flashing to both slots (although I'm sure there are other reasons to, I just can't recall what they are or seeing them); as a reboot would clumsily boot into the OS after the flash-all and you'd have to go through some trouble to get back into the bootloader and switch slots to flash again...2Whoohooo! [MOD][Xposed+Magisk][Pre-Release] AOSP Mods - System modifications for AOSP-based Android 12+ v2.7.1 has:
among other things! Glad to have it back.2
Let me explain the error in v34.0.0:
As we all know the partition /super contains a few dynamic partitions. These dynamic partitions only can be handled in userspace by fastbootd mode (which is an executable binary inside the recovery's ramdisk). To flash /super there are two existing methods:
1. In bootloader mode by flashing a super.img to /super.
2. In fastbootd mode by flashing the single dynamic partitions inside of /super.
The firmware of a Pixel has got no super.img inside it, but instead of this another zip archiv (imagesXXX.zip) with all dynamic partitions and a super_empty.img. The super_empty.img is only a partition table of /super with all start/end blocks of the dynamic partitions. These start/end blocks may change with every new firmware build and that's why they are called "dynamic".
For flashing the Pixel's firmware the commandfastboot flashallis used by Google. The flashing process starts in bootloader mode to flash bootloader.img + radio.img and then the flashing routine behindfastboot flashallhas to decide whether to stay in bootloader mode or to switch into fastbootd mode. For Pixel devices fastboot should switch into fastbootd mode to flash the single dynamic partitions. But it won't and that's the error in v34.0.0.!
Instead of this fastboot remains in bootloader mode and tries flashing /super with a super.img. Let's have a look again at the error message that users get:
Code:Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid) fastboot: error: Command failed
Due to the fact that there's no super.img (neither as a raw image nor as a sparse image) fastboot outputs that error message above. The reason for getting this error you'll find in the source (line 249):
C++:RetCode FastBootDriver::Download(const std::string& partition, struct sparse_file* s, uint32_t size, size_t current, size_t total, bool use_crc, std::string* response, std::vector<std::string>* info) { prolog_(StringPrintf("Sending sparse '%s' %zu/%zu (%u KB)", partition.c_str(), current, total, size / 1024)); auto result = Download(s, use_crc, response, info); epilog_(result); return result; } RetCode FastBootDriver::Download(sparse_file* s, bool use_crc, std::string* response, std::vector<std::string>* info) { error_ = ""; int64_t size = sparse_file_len(s, true, use_crc); if (size <= 0 || size > MAX_DOWNLOAD_SIZE) { error_ = "Sparse file is too large or invalid"; return BAD_ARG; }
In short: If sparse_file size is 0 Byte or less (= no sparse_file) than output error text "Sparse file is too large or invalid".
Why does this error occure since v34.0.0?
The developer David Anderson thought it was a good idea not to boot into fastbootd mode as much as really, really needed. He wanted to save time during the flashing process (round about 50 sec.). See fully detailed in the spoiler below.
fastboot: Avoid reboots to userspace when using flashall/update.
Reboots to fastbootd (userspace fastboot) take a long time, particularly
due to the orange AVB screen and the likelihood of devices having uart
enabled. For "flashall", there is rarely a need to actually go into
userspace, because all of super is getting thrown away. We can just
flash super in the bootloader.
In the past we didn't do this because computing super.img is expensive -
both in terms of time (due to reading dependent images) and in terms of
space (it's easily over 5GB).
But we don't actually need to fully compute super.img. We can build a
sparse_file containing the metadata/headers, with additional references
to each image file containing partition data. Liblp provides the API to
do that, and here, we simply need to translate the layout to libsparse.
On Pixel, this reduces flashall time by around 35-50 seconds, or around
20% of total time, depending on whether uart is in use.
There are some caveats, in which case we'll fall back to normal
fastbootd. This does not work on non-A/B devices, on retrofit dynamic
partition devices (Pixel 3), and in some other edge-casey scenarios. If
it fails, -v will add logging information about why.
Bue: 266982466
Test: fastboot flashall on Pixel 5+
Change-Id: Ie040da597d739faa7f834202184cec8f8e412076
(source: https://android.googlesource.com/platform/system/core/+/667b1efadd8ce8d8cf19d0684a871125cce203d3)
But something went wrong during the execution of his code. As a result of this the flashing process ends with an error and without flashing the contents of /super.
Following the log of the repo /android/platform/system/core/refs/heads/master/./fastboot several changes were made till today. But we'll have to wait for the next update, which will (hopefully) be officially released soon.
I hope it is somewhat understandable.1
Quite understandable. I actually pondered whether this was the reason for the issue a couple of weeks ago here, but didn't look into it in depth as you did.Let me explain the error in v34.0.0:
As we all know the partition /super contains a few dynamic partitions. These dynamic partitions only can be handled in userspace by fastbootd mode (which is an executable binary inside the recovery's ramdisk). To flash /super there are two existing methods:
1. In bootloader mode by flashing a super.img to /super.
2. In fastbootd mode by flashing the single dynamic partitions inside of /super.
The firmware of a Pixel has got no super.img inside it, but instead of this another zip archiv (imagesXXX.zip) with all dynamic partitions and a super_empty.img. The super_empty.img is only a partition table of /super with all start/end blocks of the dynamic partitions. These start/end blocks may change with every new firmware build and that's why they are called "dynamic".
For flashing the Pixel's firmware the commandfastboot flashallis used by Google. The flashing process starts in bootloader mode to flash bootloader.img + radio.img and then the flashing routine behindfastboot flashallhas to decide whether to stay in bootloader mode or to switch into fastbootd mode. For Pixel devices fastboot should switch into fastbootd mode to flash the single dynamic partitions. But it won't and that's the error in v34.0.0.!
Instead of this fastboot remains in bootloader mode and tries flashing /super with a super.img. Let's have a look again at the error message that users get:
Code:Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid) fastboot: error: Command failed
Due to the fact that there's no super.img (neither as a raw image nor as a sparse image) fastboot outputs that error message above. The reason for getting this error you'll find in the source (line 249):
C++:RetCode FastBootDriver::Download(const std::string& partition, struct sparse_file* s, uint32_t size, size_t current, size_t total, bool use_crc, std::string* response, std::vector<std::string>* info) { prolog_(StringPrintf("Sending sparse '%s' %zu/%zu (%u KB)", partition.c_str(), current, total, size / 1024)); auto result = Download(s, use_crc, response, info); epilog_(result); return result; } RetCode FastBootDriver::Download(sparse_file* s, bool use_crc, std::string* response, std::vector<std::string>* info) { error_ = ""; int64_t size = sparse_file_len(s, true, use_crc); if (size <= 0 || size > MAX_DOWNLOAD_SIZE) { error_ = "Sparse file is too large or invalid"; return BAD_ARG; }
In short: If sparse_file size is 0 Byte or less (= no sparse_file) than output error text "Sparse file is too large or invalid".
Why does this error occure since v34.0.0?
The developer David Anderson thought it was a good idea not to boot into fastbootd mode as much as really, really needed. He wanted to save time during the flashing process (round about 50 sec.). See fully detailed in the spoiler below.
fastboot: Avoid reboots to userspace when using flashall/update.
Reboots to fastbootd (userspace fastboot) take a long time, particularly
due to the orange AVB screen and the likelihood of devices having uart
enabled. For "flashall", there is rarely a need to actually go into
userspace, because all of super is getting thrown away. We can just
flash super in the bootloader.
In the past we didn't do this because computing super.img is expensive -
both in terms of time (due to reading dependent images) and in terms of
space (it's easily over 5GB).
But we don't actually need to fully compute super.img. We can build a
sparse_file containing the metadata/headers, with additional references
to each image file containing partition data. Liblp provides the API to
do that, and here, we simply need to translate the layout to libsparse.
On Pixel, this reduces flashall time by around 35-50 seconds, or around
20% of total time, depending on whether uart is in use.
There are some caveats, in which case we'll fall back to normal
fastbootd. This does not work on non-A/B devices, on retrofit dynamic
partition devices (Pixel 3), and in some other edge-casey scenarios. If
it fails, -v will add logging information about why.
Bue: 266982466
Test: fastboot flashall on Pixel 5+
Change-Id: Ie040da597d739faa7f834202184cec8f8e412076
(source: https://android.googlesource.com/platform/system/core/+/667b1efadd8ce8d8cf19d0684a871125cce203d3)
But something went wrong during the execution of his code. As a result of this the flashing process ends with an error and without flashing the contents of /super.
Following the log of the repo /android/platform/system/core/refs/heads/master/./fastboot several changes were made till today. But we'll have to wait for the next update, which will (hopefully) be officially released soon.
I hope it is somewhat understandable.
I was also going by Google saying they discovered the cause, were working on a fix and then following the trail where they referenced this bug in the commit Displax mentioned, which also seemed logical to me. -
9
https://source.android.com/docs/setup/about/build-numbers#build-ids-defined
First character is the version code of the release of Android, in this case Tiramisu (T) which is Android 13.
The second character is the branch of device platform that the build is from.
- D: Device specific branch, what the device launches with until the next branch merge.
- P: Primary branch, designates release branch for a successive version of Android for the device.
- Q: Quarterly platform release, the feature drops that happen every quarter.
The date roughly corresponds to when it was branched, but is mainly used to distinguish what the security patch level for release builds. Developers builds are closer to the true time it was branched.
The next three digits relate to versions based on that dated branch, and differ when a telecom needs a larger change, for example in the radio firmware or other larger change.
The last two characters are hotfixes, which usually include small changes for telecoms that need something like their APN changed after the date branch.
In this case TQ1A.230205.002 is Android 13 QPR1 that includes security patch 2023-02-05, and TQ2A.230305.008 is Android 13 QPR2 that includes security patch 2023-03-05.7Did my usual prep for the March update and everything went fine.
- Unhid Magisk
- Patched init_boot
- Edited Flash-all.bat by removing -w and adding -disable-verity and -disable-verification.
- Ran edited Flash-all
- Flashed modified init_boot
- Restored AOSPmod
- Hid Magisk
Just waiting for an updated kernel from Kiri6
So, here is the commit with fix. Waiting to merge.
5
Have a look at your bootloader.img + radio.img. The device's name of a Pixel 7 Pro is "cheeta" and "bramble" (like yours) is the Pixel 4a 5G.5
tried to flash the latest build of AncientOS with it, did not work. Back to r33.0.3 and it worked fine -
59Pixel 7 Pro [Cheetah]
Note that more than three users have said that 34.0.1 did not work correctly for them. I recommend sticking with 33.0.3 (just below these quotes)
Someone reported it to Google (added a comment about 34.0.1 to the existing 34.0.0 report).
The download links for 33.0.3:
March 13, 2023
Download links working now, and thanks to @Ghisy for making me aware the links were up:
Factory Images for Nexus and Pixel Devices | Google Play services | Google Developers
developers.google.com
13.0.0 (TQ2A.230305.008.A3, Mar 2023, WINDTRE/Canada) Flash Link da1d99156fa03162ee8216277a8ff06b626f16efbc7e8b5d12096c5a10ede1ef 13.0.0 (TQ2A.230305.008.C1, Mar 2023) Flash Link cefc4e564cb920af510a44a9cdb982ba4e8af879f6796490e03128f12f92189e
https://support.google.com/profile/79501506
(revised v1.1 March 8, 2023)Android Security Bulletin—March 2023 | Android Open Source Project
source.android.com
Here there be dragons.
I am not responsible for anything at all. 
VERY IMPORTANT - On the Pixel 7/Pro, we use Magisk to patch
Thanks to @edcsxz, @Lughnasadh, and @AndyYan for news about that and confirming it.init_boot.img, NOT boot.img AND we flash the patched init_boot to the init_boot partition - do not flash it to the boot partition.
Moved @mariusnoor's provided zero-day OTA.zip to Post #8 - Old news from the OP.
INDEX:
- Post #2 - Unlocking Bootloader / Rooting / Updating | SafetyNet | ADB/Fastboot & Windows USB Drivers:
- How to Root the first time / aka How to unlock the Bootloader
- TL;DR - for the seasoned repeat users
- Unlocking Bootloader (required in order to root)
- How to update each month (and also how to root)[requires an unlocked bootloader for updating via this factory image method]
- OPTIONAL: If you want to flash both slots, after this first time, then after do the following
- SafetyNet
- Optional steps when updating - flashing custom kernels
- The two schools of thought on disabling Verity and Verification
- ADB/Fastboot and Windows USB Drivers - direct download links and the most recent changelog
- Post #3 - Other, most important resources:
- A list of other important apps
- TWRP [not made for the Pixel 7 (or 6) Pro yet - will update when or if ever it has - don't hold your breath]
- Factory Images (requires an unlocked bootloader)
- Full OTA Images(doesn't require an unlocked bootloader - you can ask questions in this thread, but I won't be providing the steps necessary, as I always use the factory image)
- @mariusnoor's provided official URL to download the zero-day OTA to
TD1A.220804.031.
- @mariusnoor's provided official URL to download the zero-day OTA to
- Check warranty status
Official Google Pixel Update and Software Repair(reported as of January 23, 2022 to still not be updated for the Pixel 6/Pro - no idea if it has yet now, or if it will be for the 7/Pro)- Official Google Pixel Install fingerprint calibration software (also available at the bottom of the Update and Software Repair page above) - I believe this is only helpful if you've replaced the screen - if it's anything like the Pixel 6 Pro: if you have the screen replaced, then you *must* have the fingerprint reader replaced as well.
- Find problem apps, Magisk, and LSposed Modules by (three different methods)
- Official Google Android Flash Tool (OEM Unlocking needs to be toggled on - you do not have to manually unlock the bootloader - their site will do that on its own)
- How to determine if you already have Verity and Verification disabled (required for custom kernels for now)
- How to unroot
- Post #4 - Build ID definitions
- Post #5 - Blank
- Post #6 - Regarding P7P 5G model numbers and capabilities, and how to determine your hardware version
- Post #7 - My personal advice for how to get your device back up and running as you had it before a factory reset
- Post #8 - Old news from the OP
Thank you to the following users who have all contributed greatly to my knowledge of Pixels since I came back to XDA a year ago after a few years of mostly inactivity. Apologies if I miss anybody. In alphabetical order:
40Unlocking Bootloader / Rooting / Updating | SafetyNet | ADB/Fastboot & Windows USB Drivers
Unlocking Bootloader / Rooting / Updating:
How to Root the first time / aka How to unlock the Bootloader:
Unlocking the bootloader will factory reset your device. There is no way around this. I highly suggest never re-locking your bootloader once you unlock it. If you do ever re-lock the bootloader, only do so after restoring the phone to 100% stock by using the latest Pixel 7 Pro Factory Image or Official Google Android Flash Tool.
Verizon variants:
T-Mobile and AT&T variants:
The direct-from-Google (or other retailers who aren't U.S. Carriers), the factory Carrier Unlocked Pixels:
The rest of the world's carriers:
Other than trying the things I mentioned above, there is nothing else that anyone on XDA can do to help get OEM unlocking to be ungrayed.
Unlocking Bootloader (required in order to root)
How to update each month (and also how to root) [requires an unlocked bootloader for updating via this factory image method]
- These three instructions only apply if you're already rooted and updating from one firmware version to another:
- Made sure all Magisk Modules have been updated.
- Disable all Magisk Modules.
- UNhide Magisk!
- If you are going to use the Official Google Android Flash Tool, then skip the steps I indicate with FAB(Flash-All.Bat).
- If using the Android Flash Tool to update/dirty flash, you should have the following items notselected:
- Deselect Wipe
- Deselect Force Flash all partitions (which will also wipe)
- Deselect re-lock bootloader
- If using the Android Flash Tool to update/dirty flash, you should have the following items notselected:
- Always use the latest ADB/Fastboot (SDK Platform Tools) and Windows USB Drivers.
- Unzip the Platform Tools.
- Download the latest Pixel 7 Pro Factory Image (at the bottom of the "Cheetah" section).
- Unzip the factory image to the same
platform-toolsfolder, i.e. so that flash-all.bat and all other files are in the same folder as ADB and Fastboot from the platform-tools. - * FAB VERY important - Edit the
flash-all.bat(on Windows) orflash-all.sh(on Linux) and remove the-wfrom thefastboot update image-cheetah-etcetera.zipline. This will keep the script from wiping your phone when you run it. - Extract only the
init_boot.imgfile from theimage-cheetah-etcetera.zipto the sameplatform-toolsfolder. - Copy the init_boot.img from the PC to the phone's internal storage.
- On the phone: Apply Magisk Stable to the new stock
init_boot.img. NOTE: It is always possible that an Android Update (Monthly, QPR [Quarterly Platform Release], new major Android versions, and Beta versions) might need a new version of Magisk Stable, Beta, or Canary from GitHub to work correctly. XDA forum for Magisk is here.- Launch the Magisk app.
- Beside "Magisk", click "Install".
- Click "Select and Patch a File", and choose the init_boot.img that you just copied to the phone's storage.
- Copy the Magisk'd init_boot.img (filename similar to
magisk_patched-25200_1a2B3c.img)back over to the computer. - * FAB Run commands:
Code:adb reboot bootloader flash-all.bat (on Windows) or flash-all.sh (on Linux) (Note: At least two Apple Macintosh users had trouble using the flash-all.sh - at least one of those users, everything went smooth once they used a Windows PC for this part of the process)IMPORTANT - The flash-all will take several minutes and reboot on its own several times including to a mode called "FastbootD", and finally reboot into full Android when it's done. Do not interrupt this process. On the FastbootD screen on the phone, do not use any of the manual selection options - let the flash-all script do it's work. Do not unplug your phone until it has fully booted into Android.
Thanks to @PurppleMonkey and @xgerryx for suggesting a warning about this. Thanks to @simplepinoi177 for suggesting the "FastbootD" clarification. - On the phone:
- Wait for the phone to boot normally.
- OPTIONAL: If you want to flash both slots, after this first time, then after do the following:
Code:adb reboot bootloader fastboot --set-active=other flash-all.bat
- On the computer:
- Open a Command Prompt and navigate to the
platform-toolsfolder. - Run command:
Code:adb reboot bootloader - After phone has rebooted into Bootloader (Fastboot) mode, run command:
Code:fastboot flash init_boot magisk_patched-25200_1a2B3c.img fastboot reboot
- Open a Command Prompt and navigate to the
- Unlock the phone.
- Confirm that the phone boots completely normally.
- Cautiously re-enable Magisk Modules.
- Reboot.
- Confirm everything worked fine.
- If the phone won't boot correctly after having enabled Magisk Modules, see either of the two solutions below:
-
- Find problem apps, Magisk, and LSposed Modules by (three different methods) section in my next post. After following that link, you may have to scroll up a little bit and the section title will be highlighted.
-
SafetyNet:
Use whichever of these is newer than the other:
- @Displax Universal SafetyNet Fix Mod on XDA.
- Official Universal SafetyNet Fix released by @kdrag0n available at XDA.
Optional steps when updating - flashing custom kernels:
ADB/Fastboot & Windows USB Drivers:
Platform Tools was updated in August 2022 to v33.0.3 (don't use the newer v34.0.0 - it has issues):
22
Indeed. My MOD is a temporary solution until kdrag0n release accurate fix.
I didn't change the update channel in the module on purpose so that everyone can upgrade to the new official version automatically without any problems.21Other, most important resources
A list of other important apps: - be sure to thank the respective OPs:
- Here's the Magisk section of XDA's forums, for rooting. Magisk on GitHub.
- @[email protected]'s section for Nova Launcher / Nova Launcher Prime - been using this since early 2012!
- @capntrips' thread [DEV] Kernel Flasher
- [KERNEL] CleanSlate |S2S|AdBlock|VIB|BatterySvr - Thanks @tbalden!
- [Kernel] [Android Stable]Kirisakura for Pixel 7/Pro aka "Pantah" - thanks @Freak07!
- [KERNEL]Despair Kernel - Thanks @DespairFactor!
- Multi Timer StopWatch - this multiple timer app is the bomb. Got widgets, customization like crazy, you name it.
- See my review with screenshots about Multi Timer StopWatch here.
- @Chainfire's thread [APP][5.0+][2020.12.22] CF.lumen v3.74 - I used to use this app to enable my phones to go extra dim before Android developed the better native capability for that, and the app has been confirmed to work on the Pixel 7 Pro for color control, too
- @jorrik98's thread [Themes / Apps / Mods] Better Internet Tiles - Bring back Wi-Fi and mobile data toggles! (non-root)
- @VR25's thread Advanced Charging Controller (ACC)
- AccA (Advanced Charging Controller App)
- @siavash79's thread [MOD][Xposed+Magisk][Pre-Release] AOSP Mods - System modifications for AOSP-based Android 12+. This is a big one for me, personally.
- @Quinny899's thread [APP][ROOT][11+][19/07] Classic Power Menu - Power Menu Replacement w/ Wallet, Controls on Android 11, 12, 13+
- Swift Backup
- @j4velin's thread [APP] Wallpaper Changer - been using this since mid-2011!
- @Jawomo's thread [Themes / Apps / Mods] aodNotify - Notification Light / LED - see my post in that thread here for the proper offsets to use the front camera notification circle on the Pixel 7 Pro.
- @Jawomo's thread [APP] dynamicSpot - iPhone 14 Pro Dynamic Island for android!
One of these two options:
- Official Google Android Flash Tool (OEM Unlocking needs to be toggled on - you do not have to manually unlock the bootloader - their site will do that on its own).
Select the options to:- Wipe
- Force flash all partitions
- Re-lock bootloader
- Flash the completely stock init_boot.img from the same firmware version that you're on:
Code:adb reboot bootloader fastboot flash init_boot init_boot.img
TWRP [not made for the Pixel 7 (or 6) Pro yet - will update when or if ever it has - don't hold your breath]
Factory Images (requires an unlocked bootloader)
Full OTA Images (doesn't require an unlocked bootloader - you can ask questions in this thread, but I won't be providing the steps necessary, as I always use the factory image)
Check warranty status - *may* reveal if a phone is refurbished, only if the phone was refurbished through Google - thanks to @Alekos for making me aware of the site.
Official Google Pixel Update and Software Repair(reported as of January 23, 2022 to still not be updated for the Pixel 6/Pro - no idea if it has yet now, or if it will be for the 7/Pro)
Official Google Pixel Install fingerprint calibration software (also available at the bottom of the Update and Software Repair page above) - I believe this is only helpful if you've replaced the screen - if it's anything like the Pixel 6 Pro: if you have the screen replaced, then you *must* have the fingerprint reader replaced as well.
Find problem apps, Magisk, and LSposed Modules by (three different methods):
- Google's Help Page for Find problem apps by rebooting to safe mode - this can be a lifesaver and keep you from having to do a restore to 100% complete stock or even from having to do a factory reset. This will deactivate all Magisk modules, and they'll remain deactivated even after you boot normally after briefly booting to safe mode. You can re-enable the Magisk modules as you wish to try to narrow down the problem if it was caused by a Magisk module. This can even get things working again after a Magisk Module wasn't finished installing and potentially causing a bootloop.
- You can also follow @Jon8RFC's advice:
Worked for me yesterday when I accidentally tried some old version of a Magisk Module. You have to reinstall your Magisk Modules, but if you're using a third-party widget, it won't disable them like Safe mode does. - (May only be for mis-behaving LSposed modules):
Official Google Android Flash Tool (OEM Unlocking needs to be toggled on - you do not have to manually unlock the bootloader - their site will do that on its own)
How to determine if you already have Verity and Verification disabled (required for custom kernels for now)
Alternative two more manual ways of checking:I keep seeing this asked, so I added a Magisk module for it to the linked Github release. With the module installed, you can just run:
Code:su avbctl get-verity avbctl get-verification
I spent way more time debugging that I downloaded Github's HTML of theupdate-binaryscript rather than the raw file than I care to admit.
Off to bed.
- Post #2 - Unlocking Bootloader / Rooting / Updating | SafetyNet | ADB/Fastboot & Windows USB Drivers:
