[CLOSED]Rooting Android 12 on SD765G and Tensor Pixels - Android Software/Hacking General [Developers Only]

Update 12/15/21: Magisk Canary 23016 includes a fix for the vbmeta header that addresses this issue. Requesting mods close this thread.
Spoiler: Information about the issue, if you care to read it
***This is not a guide, please refer to your device forum for root instructions! Do not ask support questions here!***
Users of the Pixel 4a 5g, 5, 5a, and 6 series have all discovered a similar issue: Permanent root on Android 12 seems to require a data wipe.
Some points of note:
Previously, on Android 11 and prior, root was simple. Patch the boot image with Magisk, then flash it. No other steps were required.
However, when the Android 12 Beta launched, users of the Pixel 4a 5g, 5, and 5a discovered that Magisk patched boot images caused a "failure to load/verify boot images" message in bootloader.
This was successfully avoided on 12 Beta by disabling DM-verity and vbmeta verification, accomplished by flashing /vbmeta with these flags:
Code:
fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img
With the 12 Stable release, we have found a new issue:
If verity and verification are disabled on an existing system, the device will boot into Rescue Party, with the message "Can't load Android system. Your data may be corrupt". At this point, the user must either reflash both /boot and /vbmeta to stock, or perform a factory reset. A patched boot image can be live booted as long as both partitions are stock; this can be used for temporary root.
Alternatively, a clean install performed with the factory image, either via Android Flash Tool, or via ADB using the following command:
Code:
fastboot update -w --disable-verity --disable-verification update codename-image.zip
will also allow successful boot of a patched boot image.
If /vbmeta is reflashed without disable flags at any point, and the device is allowed to boot, disabling it again will cause the device to boot into Rescue Party.
So, it would seem users of Android 12 on the Snapdragon 765G and Tensor devices have a choice after upgrading to Android 12:
Retain data and either go without root, or use temporary root
Wipe data for permanent root
Both the verified boot issue as well as the data wipe issue affect the Pixel 6 /P6 Pro as well.
As mentioned above, a patched boot image can be live booted for temporary root even if verity/verification are not disabled and /boot is stock.
Reference threads:
Verified Boot information
Update + Magisk thread
OTA sideload thread
Upgrade results and discussion thread
Pixel 6 Pro root thread

ipdev said:
Device side actually.
Combination of hardware firmware and software.
Android 11 introduced boot header v3.
This is the start of GKI (Generic Kernel Image) support and the introduction of the vendor boot image.
The device (vendor) specific info is moved into the vendor_boot.img instead of the main boot.img.
On boot everything is combined to hopefully boot the device.
Android 12 introduces boot header v4.
This is the same as v3 with the addition of support for multiple ramdisks in the vendor boot image.
Again everything is combined on boot.
Since the 4a (5G), 5 and 5a were released with Android 11, they will use header v3 unless Google takes the time to update the build tree, kernel tree and blobs for each device to support v4.
So next year when Android 13 comes out, they will most likely still be using boot header v3.
The 6 and 6 Prop are released with Android 12 so, they will use header v4.
Again unless Google takes the time to update the trees and blobs to support a new boot header version.
One of the security updates in Android 12 (SDK31) causes the boot failure when a different boot image is installed without a data wipe.
I thought I read something about it but, I can not find where I read it.
Something about a change to the way the hash value is verified on devices using boot header v3 and newer.
Sad to say it is not a Magisk issue even though it affects Magisk.
Just unpacking and repacking the original boot image (no modification) will give the corruption error and force a data wipe if you install the repacked boot image.
Cheers.
Click to expand...
Click to collapse
@ipdev does this mean that we may potentially have to wipe /data every single time vbmeta is flashed, unless we follow the OTA sideload method? As far as that goes, why does it only seem to succeed after the OTA is sideloaded?
Anonshe said:
For the monthly updates, you've to flash the OTA packages via recovery and boot into fastboot immediately to keep vbmeta disabled. Secure boot will then remain turned off, allowing a patched boot image to be booted/flashed.
I've tested this between the betas and stable version. My last test was from Beta 5 to stable where I flashed the OTA via recovery, rebooted to bootloader, ran the fastboot command, and rebooted device. As a result, no data was lost as a wipe wasn't required.
Click to expand...
Click to collapse
I mean this is better than not having a workaround.

Ref to the GitHub issue for those wanting to keep an eye on progress (of Magisk colaborators):
https://github.com/topjohnwu/Magisk/issues/4343
PW

pndwal said:
Ref to the GitHub issue for those wanting to keep an eye on progress (of Magisk colaborators):
https://github.com/topjohnwu/Magisk/issues/4343
PW
Click to expand...
Click to collapse
It is a locked thread. Not much more to come from it that we don't already know.

mkhcb said:
It is a locked thread. Not much more to come from it that we don't already know.
Click to expand...
Click to collapse
... That's why I said 'progress of Magisk colaborators'... Others will just have to post here! PW

V0latyle said:
@ipdev does this mean that we may potentially have to wipe /data every single time vbmeta is flashed, unless we follow the OTA sideload method? As far as that goes, why does it only seem to succeed after the OTA is sideloaded?
I mean this is better than not having a workaround.
Click to expand...
Click to collapse
I have been waiting for the November update to test updating Android 12.
We will find out in a few days when it is released.
Currently I think we have a good chance to update from the Android 12 October build to the November build without having to wipe data.
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.
I have mentioned before (in a different thread), I update using the full factory image and modify the flash-all script.
This is what I plan to try.
Code:
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader
The skip-reboot option will leave the device in fastboot_d so I add a reboot to bootloader.
If nothing else needs to be flashed after the update, I just fastboot reboot.
Long (still continuing) story short.
Once Android 12 is installed, verity and verification are disabled and data is wiped.
You can flash the boot partition as much as you want on Android 12.​​You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.​The --skip-secondary is not needed, I just included it to speed up the flash a bit. ​
I still do not know what the trigger is for the corruption error.
---
As I mentioned in the post you quoted.
The corruption issue has to do with verifying the boot partition on Android 12.
Unless data is wiped after disabling verity and verification.
Since Magisk lives in boot, it unpacks, modifies, repacks and flashes the modified boot image to the boot partition.
It is not Magisk itself that triggers the corruption error, it is simply just a different boot image installed.
The same happens with a repacked (non modified) version of the stock boot image.
I used AIK to unpack and repack the stock boot image with no modification.​
Cheers.
PS.
@osm0sis
I know you are aware of this issue with Magisk but, it also affects AIK and probably AK3.
Basically anything that modifies the installed boot partition.
Code:
[[email protected] AIK-Linux]$ ./unpackimg.sh redfin-sp1a.210812.015-boot.img
Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers
Supplied image: redfin-sp1a.210812.015-boot.img
Setting up work folders...
Image type: AOSP
Signature with "AVBv2" type detected.
Splitting image to "split_img/"...
ANDROID! magic found at: 0
BOARD_KERNEL_CMDLINE
BOARD_PAGE_SIZE 4096
BOARD_OS_VERSION 12.0.0
BOARD_OS_PATCH_LEVEL 2021-10
BOARD_HEADER_VERSION 3
BOARD_HEADER_SIZE 1580
Unpacking ramdisk (as root) to "ramdisk/"...
Compression used: lz4-l
4937 blocks
Done!
[[email protected] AIK-Linux]$ ./repackimg.sh --original --origsize
Android Image Kitchen - RepackImg Script
by osm0sis @ xda-developers
Repacking with original ramdisk...
Getting build information...
kernel = redfin-sp1a.210812.015-boot.img-kernel
ramdisk = redfin-sp1a.210812.015-boot.img-ramdisk.cpio.lz4
cmdline =
os_version = 12.0.0
os_patch_level = 2021-10
header_version = 3
Building image...
Using format: AOSP
Padding to original size...
Done!
Also the modified boot image can not boot into fastboot_d while failing verification.
We are droped back to bootloader or recovery's Rescue Party when verification fails.
As noted above, the only way to disable verity and verification includes wiping data.
PPS.
Quick note for those trying to following along.
fastboot_d is part of the boot image (not the bootloader) and is the boot mode used to flash critical partitions.
The successor to fastboot flashing unlock_critical​

AIK not yet supporting hdr_v4 aside, it also can't AVBv2 sign anything (yet...), so thar also be dragons trying to flash anything unsigned on a device that wants all partitions signed.

@ipdev the problem is, as I stated, verity and verification are only disabled when vbmeta is flashed using those command line
ipdev said:
I have been waiting for the November update to test updating Android 12.
We will find out in a few days when it is released.
Currently I think we have a good chance to update from the Android 12 October build to the November build without having to wipe data.
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.
Click to expand...
Click to collapse
It doesn't seem to matter what you did initially, though. Case in point: I'm currently running permanent root on the 210812.015 build; I did a factory clean install on Saturday. If I flash vbmeta again, whether via the update or manually, it will require me to wipe data.
ipdev said:
I have mentioned before (in a different thread), I update using the full factory image and modify the flash-all script.
This is what I plan to try.
Code:
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader
The skip-reboot option will leave the device in fastboot_d so I add a reboot to bootloader.
If nothing else needs to be flashed after the update, I just fastboot reboot.
Click to expand...
Click to collapse
It sounds like this is similar to sideloading the OTA, then entering fastboot and flashing /vbmeta and /boot manually. It's worked before of course but we aren't really worried about the update not working...
ipdev said:
Long (still continuing) story short.
Once Android 12 is installed, verity and verification are disabled and data is wiped.
You can flash the boot partition as much as you want on Android 12.​​You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.​The --skip-secondary is not needed, I just included it to speed up the flash a bit. ​
I still do not know what the trigger is for the corruption error.
Click to expand...
Click to collapse
Unfortunately, I can state for a fact that this isn't true. If you dirty flash the factory image with the --disable flags, you will get put into Rescue Party. As I stated previously, disabling dm-verity and vbmeta verification must be done every time vbmeta is flashed - it is not permanent. But the particularly nasty thing here is that if you flash vbmeta again, even with the disable flags, you will still get thrown into Rescue Party. It's not flashing /boot that requires the data wipe; it's /vbmeta. If you disable verity and verification but leave the boot image stock, you still wind up in Rescue Party.
ipdev said:
The corruption issue has to do with verifying the boot partition on Android 12.
Unless data is wiped after disabling verity and verification.
Since Magisk lives in boot, it unpacks, modifies, repacks and flashes the modified boot image to the boot partition.
It is not Magisk itself that triggers the corruption error, it is simply just a different boot image installed.
The same happens with a repacked (non modified) version of the stock boot image.
I used AIK to unpack and repack the stock boot image with no modification.​
Click to expand...
Click to collapse
I still don't quite understand why this suddenly became an issue. Unlocking the bootloader was supposed to disable Android Verified Boot. It shouldn't be necessary for us to do anything else; flashing vbmeta is a relatively minor inconvenience compared to having to wipe and set up again every time you update.
ipdev said:
Also the modified boot image can not boot into fastboot_d while failing verification.
We are dropped back to bootloader or recovery's Rescue Party when verification fails.
As noted above, the only way to disable verity and verification includes wiping data.
PPS.
Quick note for those trying to following along.
fastboot_d is part of the boot image (not the bootloader) and is the boot mode used to flash critical partitions.
The successor to fastboot flashing unlock_critical​
Click to expand...
Click to collapse
Yeah, I noticed that....because recovery is part of the boot image.
@topjohnwu do you have any input? Obviously you can't talk about how to circumvent Android security, but perhaps you can provide more insight into this problem and explain the mechanisms involved?
Further, if this is not a Magisk issue, perhaps we should move this thread to another forum?

V0latyle said:
View attachment 5446899
We finally figured it out.
Turns out that once dm-verity and vbmeta verification are disabled, you CANNOT let the system boot with them enabled. If /vbmeta gets flashed, such as during an OTA or a factory image, and you let it boot into system, disabling verity/verification is going to require a wipe.
Unfortunately, for those of you upgrading from Android 11, there is simply no way around this - for permanent root, verity/verification must be disabled, and to disable verity/verification, /data must be clean.
I will be updating my guides shortly.
Click to expand...
Click to collapse
This is what I was referring to in my previous post.
ipdev said:
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.
Click to expand...
Click to collapse
ipdev said:
This is what I plan to try.
Code:
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader
Click to expand...
Click to collapse
ipdev said:
Once Android 12 is installed, verity and verification are disabled and data is wiped.
You can flash the boot partition as much as you want on Android 12.​You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.​The --skip-secondary is not needed, I just included it to speed up the flash a bit. ​
Click to expand...
Click to collapse
Just to clerify this last quote. I was dirty-flashing the full factory image disabling verity and verification during the update flash.
This only worked because I had already wiped data when I initially installed Android 12 clearing the the trigger.
Cheers.
Edit:
PS.
I had no issues updating to redfin-sp1a.211105.003.
Modified flash-all script.
Bash:
#!/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.
if ! [ $($(which fastboot) --version | grep "version" | cut -c18-23 | sed 's/\.//g' ) -ge 3103 ]; then
echo "fastboot too old; please download the latest version at https://developer.android.com/studio/releases/platform-tools.html"
exit 1
fi
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
sleep 5
# fastboot -w update image-redfin-sp1a.211105.003.zip
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot bootloader

Yeah. I sideloaded the OTA first, but then I dirty flashed the factory image, with only the disable options checked. Everything is good.

Thanks @ipdev and @V0latyle for the great posts, this looks like you've sorted this issue out as a solid workaround!
I'm on a Pixel 5a 5G/A11/Magisk 23, and want to go to A12. Since the Pixel 2 I too did all my updates via full system image and flash-all (del -w) using platform-tools and don't know much about OTA while maintaining root, I never needed it. @ipdev post gives me some hope because I understand that approach using the flash-all and full system images for updates because it's very familiar.
That said, can you confirm I have fully grasped the way forward based on your posts and code above?
- using latest platform-tools, update from A11 to A12 with full system image with supplied stock flash-all, leave in -w to allow the data wipe, and let it finish, of course removes root and is essentially a clean A12 (Is this correct or do I need to use the OTA for A12 instead? Do I need any disable flags on this first run?)
- using platform-tools, install the same full system image (because we don't have a newer monthly yet, so same image) again only this time use the edits in flash-all @ipdev shared (modified with the correct image name) which does a dirty full system flash (without -w, preserving /data), sets the appropriate disable flags, and will then allow using Magisk 23 to patch boot.img from the system image, and proceed to reflash it to boot as we used to do before A12 without failing.
- from that point forward, for the monthlies we can continue to update using full system image using the edited fastboot lines in @ipdev example (has no -w flag) to apply the monthly update in a way that will keep A12 from rejecting the patched boot.img to regain root.
Sorry for the lengthy post, but I really want to get this right, and I'm pretty excited and relieved that it appears we can do this all using full system images as I always have, no OTAs are required. I'm extremely grateful for this thread and the quick work of @ipdev @V0latyle @osm0sis and all the good folks working to get this sorted out.
Thanks all,
hfam

hfam said:
Thanks @ipdev and @V0latyle for the great posts, this looks like you've sorted this issue out as a solid workaround!
I'm on a Pixel 5a 5G/A11/Magisk 23, and want to go to A12. Since the Pixel 2 I too did all my updates via full system image and flash-all (del -w) using platform-tools and don't know much about OTA while maintaining root, I never needed it. @ipdev post gives me some hope because I understand that approach using the flash-all and full system images for updates because it's very familiar.
That said, can you confirm I have fully grasped the way forward based on your posts and code above?
- using latest platform-tools, update from A11 to A12 with full system image with supplied stock flash-all, leave in -w to allow the data wipe, and let it finish, of course removes root and is essentially a clean A12 (Is this correct or do I need to use the OTA for A12 instead? Do I need any disable flags on this first run?)
- using platform-tools, install the same full system image (because we don't have a newer monthly yet, so same image) again only this time use the edits in flash-all @ipdev shared (modified with the correct image name) which does a dirty full system flash (without -w, preserving /data), sets the appropriate disable flags, and will then allow using Magisk 23 to patch boot.img from the system image, and proceed to reflash it to boot as we used to do before A12 without failing.
- from that point forward, for the monthlies we can continue to update using full system image using the edited fastboot lines in @ipdev example (has no -w flag) to apply the monthly update in a way that will keep A12 from rejecting the patched boot.img to regain root.
Sorry for the lengthy post, but I really want to get this right, and I'm pretty excited and relieved that it appears we can do this all using full system images as I always have, no OTAs are required. I'm extremely grateful for this thread and the quick work of @ipdev @V0latyle @osm0sis and all the good folks working to get this sorted out.
Thanks all,
hfam
Click to expand...
Click to collapse
Hi.
You need to wipe data once after disabling verity and verification on Android 12.
After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.
I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link
I am not sure what works using the incremental (OverTheAir) updates.
---
To clean flash a12 and disable both verity and verification add the disable flags.
Code:
fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
After the initial install and wipe, you can update (dirty flash) without the -w option.
Code:
fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.
fastboot_d on newer devices.
I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.
If you just want to manually reboot the device or modify something before boot.
Example booting a Magisk patched boot image.​
--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.
Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.
Only true A/B has saved me from bad flashes. ​
When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.
Hope it helps more than confuse.
Cheers.

ipdev said:
Hi.
You need to wipe data once after disabling verity and verification on Android 12.
After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.
I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link
I am not sure what works using the incremental (OverTheAir) updates.
---
To clean flash a12 and disable both verity and verification add the disable flags.
Code:
fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
After the initial install and wipe, you can update (dirty flash) without the -w option.
Code:
fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.
fastboot_d on newer devices.​I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.​If you just want to manually reboot the device or modify something before boot.​Example booting a Magisk patched boot image.​
--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.
Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.​Only true A/B has saved me from bad flashes. ​
When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.
Hope it helps more than confuse.
Cheers.
Click to expand...
Click to collapse
Heya @ipdev!
Brother that's SO very helpful, thanks for the thoughtful and thorough reply!! As soon as I read you took the full system image approach to doing updates and saw you mention editing the flash-all to achieve success I knew I was home!! It has worked flawlessly and predictably for so many years, never even wanted to try OTA etc, and regaining root was a snap. This feels....comfortable and familiar!
This info, and the post previous from you where you shared the edits made to the flash-all in a code box make it really clear for me and I've got the confidence to give it a go once I've backed up what I need to incase it all goes pear-shaped.
My utmost gratitude, @ipdev, thanks so much for the assist, I'll report back when I've had a chance to do the upgrade and thanks again for all your help!
hfam

ipdev said:
Hi.
You need to wipe data once after disabling verity and verification on Android 12.
After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.
I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link
I am not sure what works using the incremental (OverTheAir) updates.
---
To clean flash a12 and disable both verity and verification add the disable flags.
Code:
fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
After the initial install and wipe, you can update (dirty flash) without the -w option.
Code:
fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.
fastboot_d on newer devices.​I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.​If you just want to manually reboot the device or modify something before boot.​Example booting a Magisk patched boot image.​
--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.
Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.​Only true A/B has saved me from bad flashes. ​
When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.
Hope it helps more than confuse.
Cheers.
Click to expand...
Click to collapse
I've been pretty much doing it the same as you since the Nexus 5, except removing the -w from the flash-all.bat file and using the flash-all command.
So basically, for updating & dirty flashing now (I'm on the Pixel 6 Pro) we can do the same (after already factory resetting when 1st disabling those flags from the vbmeta.img in a prior flash of course), remove the -w from the flash-all.bat file but replace it with --disable-verity --disable-verification . And everything else in that line stays the same and just use the flash-all command. Boot, patch the boot image and go back and flash that.
Or alternatively also add --skip-reboot to that line as well and flash the patched boot image after using the flash-all command, if you decided to patch the new boot.img beforehand.
Is this correct?

heya @ipdev I'm about to do this and a question occurred to me as I'm re-reading your last few posts before I take the dive. Hopefully I've got this right, but a confirmation would be really appreciated.
Once updated doing the initial wipe with the 2 required disable flags...
Code:
fastboot -w --disable-verity --disable-verification update image-barbet-sp1a.211105.003.zip
...can I just install the Magisk apk, patch a boot.img and flash that just like we always have using ADB to get to bootloader, etc, OR is there a timing element that also requires that every time I want to flash a patched boot.img, I must first do a dirty system flash using the 2 disable flags (ie. after dirty flashing system using the 2 disable flags AND before rebooting A12) that must be adhered to when flashing a patched boot.img?
Thanks again for all the help!
hfam

V0latyle said:
Yeah. I sideloaded the OTA first, but then I dirty flashed the factory image, with only the disable options checked. Everything is good.
Click to expand...
Click to collapse
Oh HELL @V0latyle I have been rereading the posts in this thread over and over and I just now randomly saw "....I will be updating my guide shortly" and it finally clicked...I had no idea!! Feel like I've been typing all around ya in this thread!! Heading to your guide now! LOL!
Thanks again to all of ya!
hfam

Lughnasadh said:
I've been pretty much doing it the same as you since the Nexus 5, except removing the -w from the flash-all.bat file and using the flash-all command.
So basically, for updating & dirty flashing now (I'm on the Pixel 6 Pro) we can do the same (after already factory resetting when 1st disabling those flags from the vbmeta.img in a prior flash of course), remove the -w from the flash-all.bat file but replace it with --disable-verity --disable-verification . And everything else in that line stays the same and just use the flash-all command. Boot, patch the boot image and go back and flash that.
Or alternatively also add --skip-reboot to that line as well and flash the patched boot image after using the flash-all command, if you decided to patch the new boot.img beforehand.
Is this correct?
Click to expand...
Click to collapse
Hi.
You seem to have it correct.
If you decide to add the --skip-reboot option the device will be left in bootloader_d since it is the last boot mode of update on newer devices.
So you will want to add a reboot to bootloader line after the update line.
You might also want to keep Windows from closing the command window after the batch script runs.
-- Intermission. --
Before I recommend something I try to test and double check it as much as I can.
It has been a while since I used Windows and wanted to test a few things.
Took longer than I thought it would.
After some updates (sdk and platform tools), and installing some new device drivers.
Trusty Windows 7 Pro (dual boot) on my trusty 2013 MackBook Air was ready to go. ​
I do not have a 6 Pro [raven] so I just used my 5 [redfin] to test.
I have a 6 [oriole] on order, should be delivered by Monday.
I edit the update script with Notepad++ since I know it is recommended to use for script files.
It does not include the Windows line ending junk.
This is what I ended up with to do a dirty reflash on my Pixel 5.
Along with keeping the command window open.
Note: For those stumbling across this post.
This is after the initial flash of Android 12 that included disabling verity, verification and wiping user data.​
Modified flash-all.bat
Code:
@ECHO OFF
:: 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.
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
:: fastboot -w update image-redfin-sp1a.211105.003.zip
:: echo Press any key to exit...
:: pause >nul
:: exit
fastboot --disable-verity --disable-verification --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
cmd /k
Probably do not need the extra ping but, why not delay a few seconds.
Then I just booted (fastboot boot) the magisk patched image (that I already patched while on the November build) and used the Direct install option in the Magisk app to install Magisk.
To close the command window (when I was done with it) a single exit command was all that was need.​
---
As for Magisk.
Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.
So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.
Then boot the Magisk patched image to make sure it works and nothing is broken.
If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.
Hope it helps more than confuse.
Cheers.

ipdev said:
Hi.
You seem to have it correct.
If you decide to add the --skip-reboot option the device will be left in bootloader_d since it is the last boot mode of update on newer devices.
So you will want to add a reboot to bootloader line after the update line.
You might also want to keep Windows from closing the command window after the batch script runs.
-- Intermission. --
Before I recommend something I try to test and double check it as much as I can.
It has been a while since I used Windows and wanted to test a few things.
Took longer than I thought it would.
After some updates (sdk and platform tools), and installing some new device drivers.​Trusty Windows 7 Pro (dual boot) on my trusty 2013 MackBook Air was ready to go. ​
I do not have a 6 Pro [raven] so I just used my 5 [redfin] to test.
I have a 6 [oriole] on order, should be delivered by Monday.
I edit the update script with Notepad++ since I know it is recommended to use for script files.
It does not include the Windows line ending junk.
This is what I ended up with to do a dirty reflash on my Pixel 5.
Along with keeping the command window open.
Note: For those stumbling across this post.​This is after the initial flash of Android 12 that included disabling verity, verification and wiping user data.​
Modified flash-all.bat
Code:
@ECHO OFF
:: 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.
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
:: fastboot -w update image-redfin-sp1a.211105.003.zip
:: echo Press any key to exit...
:: pause >nul
:: exit
fastboot --disable-verity --disable-verification --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
cmd /k
Probably do not need the extra ping but, why not delay a few seconds.
Then I just booted (fastboot boot) the magisk patched image (that I already patched while on the November build) and used the Direct install option in the Magisk app to install Magisk.
To close the command window (when I was done with it) a single exit command was all that was need.​
---
As for Magisk.
Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.
So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.
Then boot the Magisk patched image to make sure it works and nothing is broken.
If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.
Hope it helps more than confuse.
Cheers.
Click to expand...
Click to collapse
Thank you so much for the thoughtful and detailed response. And for taking the time to test it out. Very much appreciated.
You bring up a good point about landing in bootloader_d after using the --skip-reboot command. I hadn't realized that.
After using the flash-all script I do usually then patch the boot image while in the new build and go back into bootloader and flash it so I think I'll just stick with that tried and true method, as you suggested.
I also use notepad++ to edit the flash-all.bat script on my Windows 11 laptop.
I'm glad its turned out as "simple" as just replacing the -w with --disable-verity --disable-verification in the flash-all.bat script.
Big thanks to you and everyone else who has conquered Google's shenanigans once again.
P.S. Good to know you can still do stuff with Windows 7 on a 2013 MacBook Air

ipdev said:
As for Magisk.
Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.
So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.
Then boot the Magisk patched image to make sure it works and nothing is broken.
If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.
Click to expand...
Click to collapse
I've actually been thinking about this, it's probably better to patch the boot image post update anyway.
I'll update my guides.

Magisk Canary 23016 has fixed this issue.
Huge thanks to everyone who helped look into this issue, as well as the developers who effected the actual fixes:
@topjohnwu
@osm0sis
@ipdev
@pndwal
If there's anyone else I'm forgetting, let me know!
Requesting mods close this thread.

Related

[GUIDE] Install Magisk with proper support for OTA updates

Code:
* I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed.
* Please do some research if you have any concerns about features included in the products you find here before flashing it!
* YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
* Your warranty could be void if you tamper with any part of your device / software.
* Same statement for XDA.
Here's an alternative method to install Magisk that support OTA updates (copied from the Mi A1 forum and expanded )
You need a PC with Android platform tools (they exist also for MacOS and Linux). When using Windows, you should also install MiFlash tool to get the required drivers to recognize the device.
BOOTLOADER UNLOCK
First thing to do: unlock the bootloader (if you didn't already do this, obviously). Smartphones with Android One are much easier to unlock compared to other Xiaomi phones with MIUI (where you have to ask for authorization and wait for weeks).
CAUTION: when you unlock the bootloader, the phone will reset, erasing all your saved data. Backup your data before unlocking.
1. Go to Settings > System > About phone > and tap many times on "Build number" until you unlock "Developer options" (on Andoird 9 "About phone" is right at the top of the Settings app).​2. Go back to the previous page (i.e. Settings > System), where you can find now "Developer options". Go there and enable the "OEM unlocking" option (and it's better to never disable this).​3. Now you can shutdown your phone, then turn it on while holding the "Volume down" button pressed. Release it when you see the Fastboot screen You can also use the command "adb reboot-bootloader" if you already connected the phone to the PC.​4. Now connect the phone with your PC via USB cable, open an administrative command prompt, move to the directory where the Android platform tools are placed and unlock the bootloader with the following command:
Code:
fastboot oem unlock
The phone will reboot, erasing all the data.​
Now you unlocked your phone's bootloader and can continue to the next section.
MAGISK INSTALLATION
5. Download and install on the smartphone the latest version of Magisk Manager's apk available.
You need the smartphone to be connected to the internet, because Magisk won't install and won't work properly without a connection.​
6. Now you can easily download an already patched boot.img from the following list and jump straight to point 10 of this guide, or you can continue to the next point and learn to patch yourself an original boot.img
If you choose the short way, be sure that you select the patched_boot.img with the same "Build number" currently installed on your phone (see point 1 of this guide), and don't flash the file directly on the phone memory, because Magisk will not work properly (do exactly what this guide says, and you will not find problems, hopefully).
For our convenience, extract the patched_boot.img file in the same directory where Android platform tools are located.
patched_boot 9.6.4.0 (2018 July update) - patched with Magisk 17.1
patched_boot 9.6.6.0 (2018 August update) - patched with Magisk 17.1
patched_boot 9.6.8.0 (2018 September update) - patched with Magisk 17.1
patched_boot 9.6.9.0 (2018 October update) - patched with Magisk 17.1
patched_boot 9.6.10.0 (2018 November 1st update) - patched with Magisk 17.1
patched_boot 9.6.11.0 (2018 November 2nd update) - patched with Magisk 17.1
patched_boot 10.0.2.0 (2018 December upgrade to Android 9.0 Pie) - patched with Magisk 18.0
patched_boot 10.0.3.0 (2019 January update) - patched with Magisk 18.0
In case you erroneously flash those patched files directly on the phone, flash back the original boot.img via fastboot and follow the guide:
original boot.img 9.6.4.0 (2018 July update) - taken from fastboot ROM
original boot.img 9.6.6.0 (2018 August update) - taken from OTA update
original boot.img 9.6.8.0 (2018 September update) - taken from OTA update
original boot.img 9.6.9.0 (2018 October update) - taken from OTA update
original boot.img 9.6.10.0 (2018 November 1st update) - taken from OTA update
original boot.img 9.6.11.0 (2018 November 2nd update) - taken from OTA update
original boot.img 10.0.2.0 (2018 December upgrade to Android 9.0 Pie) - taken from fastboot ROM
original boot.img 10.0.3.0 (2019 January update) - taken from fastboot ROM
7. You need the original boot.img to patch. You can find it inside the official fastboot ROM zip for daisy. Check that the downloaded ROM version is the same as the "Build number" currently installed on your phone (see point 1 of this guide). If the versions are different, update (or downgrade if possible) your phone to that version. You can also download original boot.img elsewhere (for example at the point 6 of this guide), but always pick the same "Build number" of your phone.
After you get the boot.img, copy it to the phone memory (via USB or microSD, or download directly from the phone browser, as you prefer).​
8. Open the Magisk Manager app installed previously, it will ask if you want to install Magisk. Accept by tapping on "Install" > "Patch Boot Image File" and select the boot.img file that you get on the point 7 of this guide.​
9. Wait until the process completes (about 1 minute), then tap on "Close". Now in the phone memory, inside the Download directory, you should have a patched_boot.img file. Copy that file to the PC, inside the same folder where the Android platform tools are located, for our convenience.​
10. Reboot the phone in fastboot mode (as already explained in point 3 of this guide), open an administrative command prompt, move to the Android platform tools directory and then write the following command:
Code:
fastboot boot patched_boot.img
If everything works the phone should boot normally. Open Magisk Manager and it should ask to install Magisk, if not you must tap on the "Install" button. Then choose "Install" > "Direct Install (Recommended)" to install Magisk on the phone, and reboot when finished.​
11. Last step to stay safe when a new OTA update arrives: go to "Settings" > "System" > "Developer options" > and disable "Automatic system updates". From now on, you should check manually if a new OTA update is available.​
Now the installation is finished, you can use Magisk Manager to install modules and manage root permissions.
HOW TO APPLY OTA UPDATES
UPDATE 9 February 2019 It seems that with the latest Magisk (v18.1) and Magisk Manager (v7.0.0) the following procedure is working fine again. I didn't test it personally, but some users gave positive feedback.
WARNING! January 2019 Since the arrival of Android 9 Pie, the OTA update with Magisk as described in the following section, doesn't seem to work anymore. It could work, but you could also get a bootloop with the risk of losing your data.
Before upgrading from Android 8 to 9, or doing an OTA update after Android 9 you should:
- backup your data;
- remove any lockscreen password or fingerprint;
- uninstall totally Magisk and reboot.
If after doing this you get a bootloop, you could try to manually flash the vanilla boot.img via fastboot on the current slot (the same version as the last installed OTA). If you managed to fix the bootloop you can then install Magisk anew, from step 5 of this guide.
If the phone wants your PIN or password to proceed after the OTA update or after fixing the bootloop, and your PINs or passwords doesn't work, then you could have to reset the phone (or erasing the data partition, that should be the same thing), losing all your data.
Last chance if everything fails, you can flash the latest fastboot ROM from the official Xiaomi site and the phone will be working again.
IMPORTANT: OTA updates will work only if all the partitions on the smartphone are untouched. Magisk Manager can restore the original boot.img following this section of the guide, but if you tampered directly with the system partition (e.g. manually editing build.prop) or other partitions, OTA will refuse to install.
You can try to fix OTA updates without the need to flash the whole original fastboot ROM, by flashing only the tampered partitions (usually only "system") with the corresponding img file found inside the fastboot ROM zip. Check the "Troubleshooting" section of this guide for details.
12. When you know that a new OTA update is available and you want to install it, open Magisk Manager, and tap on "Uninstall" > "Restore Images" but very important: absolutely don't reboot the phone now!
Important note: Magisk Manager will restore the boot.img that was found on the phone while installing Magisk. If the boot.img was already non-vanilla (for example you flashed the boot.img with TWRP before installing Magisk), Magisk Manager will backup that modified version of boot.img, and when restored the OTA will not work, as that's not a vanilla boot.img.​
13. Close Magisk Manager and go to "Settings" > "System" > "System update" and install the OTA update. After the update is downloaded, a two-stages update will begin.​
14. When both stages of the update process completed, it will ask to restart: DON'T DO IT!. Open Magisk Manager again and tap on "Install" > "Install" > "Install to Inactive Slot (After OTA)" and after that you can tap on "Reboot".​
After the reboot you will have the updated Android version with Magisk already working.
Thanks to user @jashancheema for the Mi A1 guide and a bigger thanks to @topjohnwu for the OTA part and above all for developing Magisk.
TROUBLESHOOTING
WARNING: before attempting any of the following operations, you must disable any screen lock, PIN or password, because you risk to not get back your data (encryption issues). It is recommended to take a backup, too (as every time a custom modding is involved).
You can get errors when installing OTA updates if you didn't follow meticulously the guide.
Check this list to try to find where the problem lies:
- when a new version is found, the updater will check if all the partitions on the device are untouched. If there is a partition that has been modified, the OTA updater will not proceed with the installation;​- typically, the two partitions commonly modified by user modding are the boot partition (that's where Magisk and TWRP are installed) and the system partition (when you change a config file, add or remove a system app, etc.);​- a system partition modified only by using Magisk modules is effectively untouched, because Magisk register all changes to /system in a file in the /data partition and then trick Android to believe those changes are really applied to /system;​- boot partition instead is really modified, but if you install Magisk following this guide, Magisk will save a copy of the untouched boot partition, and restoring it before applying OTA update will make the update work.​
Now, if you didn't follow this guide to install Magisk and you installed it in other ways, Magisk could alert you that he cannot restore the original boot.img (the boot partition) when you try to apply the OTA update.
To fix this, you can flash directly the vanilla (original, unmodified, untouched) boot.img taken from the point 6 of this guide, using those commands:
Code:
fastboot getvar current-slot
fastboot flash boot_? boot.img
the first command will tell you what is the current slot in use (a or b), the second command will flash the original boot into the phone, but you have to change the "?" in the command with a or b (i.e. the current slot that the first command provided).
Remember that the boot.img file version must correspond to the Android build version currently running in your phone.
If the OTA update will still refuse to apply, probably you changed something directly in the /system partition (for example you changed something in the build.prop without using a Magisk module to do this).
In this case you have to flash the original system.img in the phone with those commands:
Code:
fastboot getvar current-slot
fastboot flash system_? system.img
and as before, the first command will tell you the right slot to use instead of the "?" in the second command.
Here you can find the system.img extracted from the OTA updates zip (along with every other .img file inside that):
9.6.6.0 (August 2018) OTA update dump as .img files
9.6.8.0 (September 2018) OTA update dump as .img files
9.6.9.0 (October 2018) OTA update dump as .img files
9.6.10.0 (November 2018) full fastboot ROM
9.6.11.0 (November 2018) OTA update dump as .img files
If you want to obtain the system.img by yourself, you can find it inside the fastboot images but usually they are not updated monthly like OTA updates. But you can extract the system.img directly from the OTA update zips found in this thread (as I did above with my dumps), using the Python scripts found here.
To make the Python scripts work in Debian/Ubuntu and derivatives, you have to download both "extract_android_ota_payload.py" and "update_metadata_pb2.py", give them execution property and then install the package "python-protobuf". After this you can give this command to unpack the payload.bin file (that you must extract from the OTA update zip):
Code:
./extract_android_ota_payload.py /path/to/payload.bin
This will extract in the current directory all the .img files inside payload.bin, including the system.img
I don't know how to proceed in Windows, probably you only need to install the latest Python2 release and the script will work.​
As the last resort, you can flash directly with MiFlash the latest fastboot image available (even if older than your current version). Use the "flash_all.bat" script but before take a backup of your data, because the phone will be fully reset.
If you don't want to take the risk of not doing a backup, use the script "flash_all_except_storage.bat" when flashing, so you will keep all your data, but be warned that sometimes you will not be able to access the data anymore, because of encryption problems.
Right after the flash, you can start following the guide from point 5 or 6.
It should not be a problem downgrading the build version via fastboot, as long as the Android main version remain the same (Oreo 8.1 at the moment).
Thx, nice work :good:
Thanks to the OP. Great post! Totally noob friendly guide. Nice work.
It should also work on mi a2, thanks!
Lione2 said:
It should also work on mi a2, thanks!
Click to expand...
Click to collapse
Sure, but you can't use the posted patched_boot.img, because they're designed for Mi A2 Lite (daisy) and not for Mi A2 (jasmine).
EDIT: I posted the patched and original boot files for Mi A2 jasmine in the second post. I don't know if I can make a thread in the Mi A2 forum section with an adapted copy of my guide, there are already two guides there (even if not polished like this) and I don't want to create more confusion with a third guide about the same argument...
i've installed magisk from previous guide - what steps should I take to apply OTA update? - 12 to 14?
Now magisk informs me that there is 17.1 version - how to update it?
krzygaj said:
i've installed magisk from previous guide - what steps should I take to apply OTA update? - 12 to 14?
Now magisk informs me that there is 17.1 version - how to update it?
Click to expand...
Click to collapse
If you flashed directly the patched_boot.img via fastboot in both slots A and B as the other guide said previously, you must flash the original boot.img to both slots, then start the guide from point 10.
BubuXP said:
If you flashed directly the patched_boot.img via fastboot in both slots A and B as the other guide said previously, you must flash the original boot.img to both slots, then start the guide from point 10.
Click to expand...
Click to collapse
I did as you wrote but still can't install August update - is there any log?
- extracted boot.img from rom: http://en.miui.com/download-354.html
- did fastboot flash boot_a boot.img and fastboot flash boot_b boot.img and rebooted
- next rebooted and did fastboot boot patched_boot.img with patched_boot 9.6.4.0 (July update) - patched with Magisk 17.1
later did steps in guide - but when i do system update it stops on first stage
Any ideas?
krzygaj said:
I did as you wrote but still can't install August update - is there any log?
- extracted boot.img from rom: http://en.miui.com/download-354.html
- did fastboot flash boot_a boot.img and fastboot flash boot_b boot.img and rebooted
- next rebooted and did fastboot boot patched_boot.img with patched_boot 9.6.4.0 (July update) - patched with Magisk 17.1
later did steps in guide - but when i do system update it stops on first stage
Any ideas?
Click to expand...
Click to collapse
You tampered the system partition? Try flashing also the system.img in that case.
Another case could be that you made an OTA update from the June build to July: in this case the partitions on the other slot (probably only the boot partition) where lost when overwrited with fastboot (and cannot be restored, as we don't have any June build ROM or OTA).
If everything fails, do a full fastboot flash with MiFlash tool, but using the flash_all_except_storage.bat script, that should keep your data intact, restore all partitions (A and B) to stock versions and you can then apply OTA (before or after installing Magisk, but I suggest after installing Magisk so you can test if the guide works fine).
BubuXP said:
If everything fails, do a full fastboot flash with MiFlash tool, but using the flash_all_except_storage.bat script, that should keep your data intact, restore all partitions (A and B) to stock versions and you can then apply OTA (before or after installing Magisk).
Click to expand...
Click to collapse
Thanks above worked :good:
Hope the next update will go smoothly

			
				
September?
When booting comes a warning message because of the unlocked boot loader. How can I disable this message?
PC295 said:
When booting comes a warning message because of the unlocked boot loader. How can I disable this message?
Click to expand...
Click to collapse
you can't turn that off with open bootloader
Guys, after i have unlocked bootloader i cannot charge my phone when is off because he go on when I insert the plug, it's normal?
proton242 said:
Guys, after i have unlocked bootloader i cannot charge my phone when is off because he go on when I insert the plug, it's normal?
Click to expand...
Click to collapse
No
ConradB said:
No
Click to expand...
Click to collapse
ConradB you have some suggestion? Thank you
proton242 said:
ConradB you have some suggestion? Thank you
Click to expand...
Click to collapse
Same problem on mine, I don't know if it's a ROM bug or it's caused by unlocked bootloader or Magisk.
The only solution at the moment is charging while the phone is switched on.
BubuXP said:
Same problem on mine, I don't know if it's a ROM bug or it's caused by unlocked bootloader or Magisk.
The only solution at the moment is charging while the phone is switched on.
Click to expand...
Click to collapse
Ciao BubuXP, provando a rimuovere Magisk (lasciando il bootloader sbloccato) tutto torna alla normalità, cosa dici, crea casino quando patcha il boot.img?

Advanced OTA keeping Magisk and TWRP (needs a computer)

History...
I originally wrote this guide to upgrade from 10.0.4.0 to 10.0.7.0.
I have also used this same guide to install every OTA from 10.0.7.0 to 11.0.11.0.
This guide assumes you have both Magisk and TWRP, that Magisk cannot "uninstall" (because of TWRP installation) and that you want to keep both Magisk and TWRP after installation. Parts of this guide may still be useful if you aren't in this exact situation.
If you only have Magisk, you should be able to follow these much simpler instructions: https://forum.xda-developers.com/mi-a2-lite/how-to/guide-install-magisk-proper-support-ota-t3836952
Things to have on hand:
- vanilla_boot.img (for the version you currently have)
- patched_boot.img (your current boot image with Magisk)
- TWRP img and zip (see version info below)
I think that TWRP also causes the vendor partition to be modified. It may also touch system but I have a modified bootanimation.zip which modifies system, so I can't be sure. In any case, I also have a backup of system.img and vendor.img.
Because Magisk is installed after TWRP, Magisk's "backup" of the "stock boot image" is not vanilla. This means that in order to take the OTA, I have to flash the vanilla boot image.
0 - Update your patched_boot.img
If you don't have a patched_boot.img for your current Magisk (eg. my patched_boot.img was old, since I had installed several Magisk updates), you should build a new patched_boot.img so that when you boot it, the system will continue to work.
Push the vanilla image to the phone.
Code:
adb push vanilla_boot.img /sdcard
Then get Magisk to install using the "Select and Patch a File" method, select the file you uploaded. Then pull down the patched image.
Code:
adb pull /sdcard/Download/magisk_patched.img patched_boot.img
1 - Prepare to OTA
For some reason, my carrier does not like the OTA process so I always turn on Airplane mode + Wifi.
Get to fastboot and check the current slot.
Code:
adb reboot bootloader
fastboot getvar current-slot
My current slot was b
Flash the system and vendor partitions (if necessary).
Code:
fastboot flash system_b vanilla_system.img
fastboot flash vendor_b vanilla_vendor.img
Flash vanilla and boot the patched image (so that Magisk is active and the OTA can be applied).
Code:
fastboot flash boot_b vanilla_boot.img
fastboot boot patched_boot.img
2 - Do the OTA
Install OTA (DO NOT REBOOT)
If the OTA fails
If the OTA fails, you can find out which partitions it doesn't like from the logcat. If you have a fastboot image, you can reflash the affected partitions. As previously mentioned, I've had to flash all of boot, vendor and system for each OTA.
Code:
adb logcat | grep update_engine
...
07-01 06:52:38.470 E/update_engine(935): [0701/065238.470683:ERROR:delta_performer.cc(990)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
07-01 06:52:38.470 E/update_engine(935): [0701/065238.470931:ERROR:delta_performer.cc(995)] Expected: sha256|hex = A4AD686D7BF628486668446221D0089BF5915DBC1158C83D30A06222FE7D2ACB
07-01 06:52:38.471 E/update_engine(935): [0701/065238.471002:ERROR:delta_performer.cc(998)] Calculated: sha256|hex = 4CADBE88EC1C019913A0B416EB9031840D4BA6B2287A3FC814A2B8B7F9871F7D
07-01 06:52:38.473 E/update_engine(935): [0701/065238.471072:ERROR:delta_performer.cc(1009)] Operation source (offset:size) in blocks: 0:5221,5461:405,5869:1,5873:343,6221:589
07-01 06:52:38.473 E/update_engine(935): [0701/065238.473233:ERROR:delta_performer.cc(1191)] ValidateSourceHash(source_hash, operation, source_fd_, error) failed.
07-01 06:52:38.473 E/update_engine(935): [0701/065238.473340:ERROR:delta_performer.cc(298)] Failed to perform BROTLI_BSDIFF operation 187, which is the operation 0 in partition "boot"
07-01 06:52:38.473 E/update_engine(935): [0701/065238.473411:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
07-01 06:52:38.739 E/SystemUpdate(15410): [Execution,NonStreamingAbApplyAction] Installation failed with error code: 20.
3 - Backup the vanilla boot image
Note that you need to pull from the other slot (in my case, a).
Code:
adb shell
su
dd if=/dev/block/by-name/boot_a of=/sdcard/vanilla_boot.img bs=1024k
Backup system.img and vendor.img too (if required).
Code:
dd if=/dev/block/by-name/system_a of=/sdcard/vanilla_system.img bs=1024k
dd if=/dev/block/by-name/vendor_a of=/sdcard/vanilla_vendor.img bs=1024k
4 - Magisk patch the other slot
Use Magisk to "Install to Inactive Slot (After OTA)" (DO NOT REBOOT)
5 - Backup the patched boot image
Note that you need to pull from the other slot (in my case, a).
Code:
dd if=/dev/block/by-name/boot_a of=/sdcard/patched_boot.img bs=1024k
exit
exit
# back on your computer
adb pull /sdcard/vanilla_boot.img
adb pull /sdcard/patched_boot.img
Pull down system and vendor images too (if required).
Code:
adb pull /sdcard/vanilla_system.img
adb pull /sdcard/vanilla_vendor.img
Now you can let Magisk reboot. This is the moment of truth...
At this point you should have an upgraded, Magisk-enabled system and backups of the vanilla and patched boot images. Congratulations on completing the OTA!
If the system fails to boot
There's a few things to try before giving up if the system fails to boot...
1) Boot without Magisk (fastboot boot vanilla_boot.img). Probably indicates that a Magisk module you have is no longer compatible.
2) Boot TWRP (fastboot boot twrp.img) and poke at things. As an example, I used the /sdcard/mm program (part of Magisk Manager for recovery) to disable EdXposed when the OTA to Android 10 failed to boot.
6 - Restore TWRP
It is possible to boot TWRP from fastboot so you don't strictly need to install TWRP. I like to have it available anyway.
Old version info...
I had been using the official TWRP 3.2.3, which worked great up until 10.0.9.0. With 10.0.9.0, I couldn't get to TWRP, I just got the system destroyed screen. I could fastboot boot it, but it couldn't mount /data (a problem it has always had).
I figured out that TWRP 3.3.1-dees_troy (from the official TWRP site) works with 10.0.9.0 and up. What's more, it works (can decrypt /data) if you fastboot boot it, not just after install. So you could in theory simply not install TWRP and fastboot boot if in the event that you actually need it.
I know that people have their own favourite versions, with the offain version being popular (didn't work for me). There's OrangeFox too (also didn't work for me).
In summary, I recommend Official TWRP 3.3.1-dees_troy but if you have a favourite alternative, feel free to use it instead.
TWRP thread: https://forum.xda-developers.com/mi-a2-lite/development/official-twrp-daisy-t3855396
Download link: https://dl.twrp.me/daisy/
Restoring TWRP is the same as installing it the first time. This is the process that I use.
Flash vanilla boot, then install TWRP to it.
Code:
adb reboot bootloader
fastboot boot twrp-3.3.1-dees_troy-daisy.img
Install TWRP
Code:
adb push twrp-installer-3.3.1-dees_troy-daisy.zip /sdcard
Use TWRP to install twrp-installer-3.3.1-dees_troy-daisy.zip
I install my modified bootanimation.zip at this time.
Mount System from TWRP (it is normally already mounted for me).
From a shell:
Code:
adb shell
cd /sdcard
cp bootanimation.zip /system/system/media/bootanimation.zip
Umount System
You must re-install Magisk after installing TWRP.
Code:
adb reboot bootloader
fastboot boot patched_boot.img
Use Magisk to "Direct Install (Recommended)"
Reboot
For some reason, my carrier does not like the OTA process so at this point I normally power off the phone rather than just rebooting. When the phone boots, I can turn off airplane mode and check that a mobile data connection can be made.
7 - Confirm that everything works
Make sure the system comes up and Magisk Manager says that Magisk is installed.
Make sure you can get to TWRP. Boot while holding VOL+ or
Code:
adb reboot recovery
Make sure TWRP can see your files.
Congratulations! You have installed an OTA while keeping Magisk and TWRP!
8 - Backup boot.img with TWRP + Magisk (optional)
If you want a copy of the boot.img with both Magisk and TWRP. This pulls from the now-current slot (in my case, a). I'm not totally sure of the value of this, since I can't get fastboot to boot this image. It may come in handy if you upgrade TWRP and that breaks (since you can flash this back rather than having to install the old TWRP again).
Code:
adb shell
su
cd /sdcard
dd if=/dev/block/by-name/boot_a of=twrp_boot.img bs=1024k
exit
exit
# back on the computer
adb pull /sdcard/twrp_boot.img
Thanks. Could you upload or indicate where we can get the necessary files?
Will i loose all user data and internal storage wiped if i do this?
Thanks for sharing, looks complicated, also i think you should use a fixed twrp, since the official dont have acces to sdcard.
rossarnie said:
Thanks. Could you upload or indicate where we can get the necessary files?
Click to expand...
Click to collapse
If you have Magisk, you should already have the vanilla and patched boot.img files.
Of you don't already have Magisk, just follow the install procedure here. https://forum.xda-developers.com/mi-a2-lite/how-to/guide-install-magisk-proper-support-ota-t3836952
If you're running 10.0.4.0 without magisk and need to extract your vanilla boot.img. Use fastboot to boot into twrp and then you can do the DD command to extract boot. Use adb pull to save it to PC.
I used official TWRP from here.
https://forum.xda-developers.com/mi-a2-lite/development/official-twrp-daisy-t3855396
Apparently there's a different twrp that can access the external SD card. I don't have an external SD card so I don't need it.
dr.bahaeddin said:
Will i loose all user data and internal storage wiped if i do this?
Click to expand...
Click to collapse
I didn't lose any data.
I've never had a problem with Magisk. TWRP does tend to bootloop after install, which is why I install magisk again.
You should be able to flash the patched or vanilla boot if twrp is boot looping to fix it too. Just won't have twrp anymore.
a1291762 said:
I didn't lose any data.
Click to expand...
Click to collapse
Mind you. I have a backup of my apps and data that's off of my phone so even if I do need to factory reset I can get it back. That's a longer and more complicated guide.
Txatxiquesi said:
looks complicated.
Click to expand...
Click to collapse
Before I had twrp the standard Magisk ota process was enough. But that loses twrp and with twrp in my magsik backup, the uninstall didn't work. So extra steps are needed. Plus some extra steps to make backups of important files for the next OTA
a1291762 said:
If you have Magisk, you should already have the vanilla and patched boot.img files.
Click to expand...
Click to collapse
Hmm... This may not be the case. I'm careful to make backups but it's easy to skip this.
If you don't have a patched boot image you can backup your current boot partition from a root shell. You need to find out if you are booting a or b slot. Then
dd if=/dev/block/by-name/boot_a of=/sdcard/patched_boot.img bs=1024k
Magisk puts old stock backups into /data. I had 4 files in there which makes it hard to know what each file is.
That's why I made sure to backup my vanilla boot image immediately.
If you're stuck without a vanilla 10.0.4.0 boot you can't do the OTA. I can upload mine somewhere when I get home tonight if it's not already online.
a1291762 said:
...If you're stuck without a vanilla 10.0.4.0 boot you can't do the OTA. I can upload mine somewhere when I get home tonight if it's not already online.
Click to expand...
Click to collapse
This would be very helpful, please
FunkmasterC said:
This would be very helpful, please
Click to expand...
Click to collapse
Here is the backup I made of the 10.0.4.0 vanilla boot.img. You'll need to decompress this before flashing.
URL REMOVED
What's new on 10.0.7.0 bro? Should me wait for 10.1 update if im on 10.0.4.0 rooted?
10.0.7.0 has the March security patches. I haven't noticed any actual changes.
Thank you, your Linux commands are sick, I never know I can get the vanilla and patched boot.img like that.
Cheer~
is there an update for file version 10.0.8.0??
I only just got the notification this morning. I'll do the upgrade tonight but I expect the same process will work.
I just used the same process to go from 10.0.7.0 to 10.0.8.0. This time I was installing to slot b instead of slot a, but otherwise, things were the same.
A side note... I hadn't got around to installing TWRP 3.3.0 so I did that but it couldn't mount /data. TWRP 3.2.3 can mount /data, so I installed that again.
a1291762 said:
I just used the same process to go from 10.0.7.0 to 10.0.8.0. This time I was installing to slot b instead of slot a, but otherwise, things were the same.
A side note... I hadn't got around to installing TWRP 3.3.0 so I did that but it couldn't mount /data. TWRP 3.2.3 can mount /data, so I installed that again.
Click to expand...
Click to collapse
I have successfully updated to 10.0.8.0 with Magisk 18.1, now on Magisk 19.1, everything is running fine. I'd like to also install TWRP but refrain from doing so because of the problems (bootloops, crashes, etc) the official TWRP 3.2.3 shows with decryption in Pie and mounting external or even internal sdcard. I wonder if the latter is fixed in the inofficial fixed version. I think the benefit of TWRP is not worth the effort of repeating a1291762 wonderful tricky procedure on the monthly OTA update basis.
However the procedure is very smart, a back-to-the-roots approach of former days... great, I like it.
But I don't understand how a patched_boot.img can be created from an empty file (boot_a)?
[dd if=/dev/block/by-name/boot_a of=patched_boot.img bs=1024k] Locating the boot_a in </dev/block/by-name/> reveals a boot_a file with 0 bytes. Moreover, to unzip the zipped stock boot Image in </data/stock_boot*.img> or </sbin/.magisk/mirror/data/> I am looking for a command that just returns the boot file rather than expanding it to the full partition. Weird, can anybody help?
Thanks again to a1291762
grufty47
It appears that it is not possible to add some boot.img as attachment
grufty47 said:
I'd like to also install TWRP but refrain from doing so because of the problems (bootloops, crashes, etc) the official TWRP 3.2.3 shows with decryption in Pie and mounting external or even internal sdcard.
Click to expand...
Click to collapse
I use official TWRP 3.2.3. Only really to fix bootloop problems.
I don't have a SD and no problems mounting data.
Lots of people following the TWRP install guide seem to get bootloop. I solve that by patching boot with Magisk. Some people recommend installing an old about image.
If you have a backup of boot you can at least restore that if you have problems.
grufty47 said:
But I don't understand how a patched_boot.img can be created from an empty file (boot_a)?
Click to expand...
Click to collapse
Welcome to Unix, where nearly everything is a file.
Hard disk? /dev/sda
Partition? /dev/sda1
File? /mnt/sda1/file.txt
In this case, boot_a is a way to access a partition on the phone's flash. Actually a link (shortcut) to /dev/mmcblk0p52. Partition number 53 on flash chip 1. The size can't be seen because it's a device and not a file.
grufty47 said:
I am looking for a command that just returns the boot file rather than expanding it to the full partition.
Click to expand...
Click to collapse
dd is a command to read a device. The partition is 64M big so that's the size of the file. gzip can compress well because the actual image is only 24M big and the rest is empty.
Magisk knows how to do it. A tool called magiskboot but I don't know where it lives or how to run it.
I found this header from magiskboot. It shows how the boot.img is structured.
https://github.com/topjohnwu/Magisk/blob/master/native/jni/magiskboot/bootimg.h
I just did the 10.0.9.0 OTA. I added a section of updating your patched_boot.img (since the Magisk updates I did made my old one useless) and I changed the backup instructions due to changes in Magisk 19. If you know where the stock boot lives before reboot, please let me know.

[UPDATE / KEEP ROOT GUIDE] MAY 2021 (RQ2A.210505.002) - "CORAL" Magisk & Stock Boot / DTBO Images

(Sorry guys, this would have been up sooner, but Android File Host hasn't been letting me upload all day for some reason, so I just temporarily uploaded May 2021's files to my Google Drive for now instead. Enjoy! --- moved back to AFH )
IMPORTANT!! THESE FILES / THIS THREAD IS FOR PIXEL 4 XL "CORAL" ONLY, NOT PIXEL 4 "FLAME"!!
**IT IS HIGHLY RECOMMENDED TO PATCH THE STOCK BOOT IMAGE YOURSELF, FROM YOUR OWN DEVICE, USING MAGISK MANAGER. WHILE THERE'S A GOOD CHANCE THE FILE I PROVIDED BELOW WILL BE IDENTICAL (USE A FILE HASH CHECKSUM TOOL IF YOU'RE CURIOUS), THERE IS ALSO A CHANCE THEY MAY HAVE SMALL, BUT SIGNIFICANT, VARIANCES**
Thanks for the info and link, @wrongway213
Link to @topjohnwu's post: twitter dot com /topjohnwu/status/1272136975022084097?s=19 (until I figure out how to stop new XDA from forcing the URL to embed a giant twitter posting in the middle of the post...)
ALL FILES BELOW ARE FOR "RQ2A.210505.002, May 2021"!
Magisk v22.1 Patched Boot Image: https://www.androidfilehost.com/?fid=2188818919693794185
Factory Untouched Boot Image: https://www.androidfilehost.com/?fid=2188818919693794183
Factory Untouched DTBO Image: https://www.androidfilehost.com/?fid=2188818919693794180
----------------------------------------------
-------------UPDATE PROCESS BELOW-------------
----------------------------------------------​
EASY UPDATE / SEAMLESS KEEP-ROOT UPDATE PROCESS (using a PC - a very intuitive, effective, and relatively safe method).
** You can only follow this guide verbatim if coming EXACTLY from build "11.0.0 (RQ2A.210405.005, Apr 2021". But the general idea is the same for other builds, you just need the correct files for your device.
coral-rq2a.210405.005-factory-dtbo.img: https://www.androidfilehost.com/?fid=2188818919693776320
coral-rq2a.210405.005-factory-boot.img: https://www.androidfilehost.com/?fid=2188818919693776321
May 2021 sideload OTA zip: https://dl.google.com/dl/android/aosp/coral-ota-rq2a.210505.002-ca3e88b3.zip
DO NOT BOOT BACK INTO O/S UNTIL ALL STEPS ARE COMPLETED - THIS ENSURES EVERYTHING BOOTS BACK UP WITH MAGISK / EDXPOSED ALL RUNNING PROPERLY RIGHT AWAY
1. boot into bootloader
----------------
** I was on custom kernel, so I needed to flash BOTH the stock boot and dtbo images
2. fastboot flash boot coral-rq2a.210405.005-factory-boot.img
3. fastboot flash dtbo coral-rq2a.210405.005-factory-dtbo.img
......* these steps to restore stock recovery; dtbo.img also necessary for some kernel installations.
......* won't hurt to flash both anyway, so if you're unsure, go ahead and do both.
-----------------
4. use volume keys to change selection to boot to Recovery Mode
......- when you reach the android symbol with No Command, hold power button, tap volume up, in case you've forgotten
5. choose option "Apply update from ADB"
6. adb sideload coral-ota-rq2a.210505.002-ca3e88b3.zip
7. Once the OTA sideload is done, Reboot to bootloader (you'll also notice it's now on the other slot after OTA flashed)
8. fastboot flash boot coral-rq2a.210505.002-magisk_patched-22100.img
9. done, start the phone
(Optional - Flash custom kernel. If you had a custom kernel, you need to re-flash it)
This is a 100% seamless update that requires no additional / re-setup of any of my Magisk or EdX/LSposed setups. All of the factory files can be found here https://developers.google.com/android/images. boot.img and dtbo.img are in their corresponding full Factory Image zips, and the ota zip is under Full OTA Images.
-------------------------------------------------
-------------------TROUBLESHOOTING-------------------
-------------------------------------------------​
Issues after updating?
If you end up unable to boot or bootlooping afterwards, you most likely have an old Magisk module that isn't playing nice with the new build. There are 2 main things you can do:
1. Flash the new factory untouched boot image. You will of course lose root, and all modules will be disabled. However, it should at least get you able to boot back up quickly and have a working phone if you're in a bind.
2. I would recommend checking Tulsadiver's thread: https://forum.xda-developers.com/pixel-4-xl/how-to/magisk-modules-disabler-booting-magisk-t3990557
Instead of reverting to stock boot image, fastboot boot (NOT FLASH) Tulsadiver's boot image. This will boot your phone in Magisk Core-Only Mode, with all modules disabled but root retained. From here you can open Magisk Manager and disable suspect modules. Before rebooting, go to Magisk Manager's settings and disable Magisk Core-Only Mode. Once you disable the incompatible module, the phone should boot back up.
- See this post (or thread) for more tips / context / an example: https://forum.xda-developers.com/showpost.php?p=82509691&postcount=16
Since Magisk v21.x, Core Only mode has been replaced by using Android's built-in Safe Mode. Booting into Safe Mode should essentially boot you back into your system but with all modules disabled (as well as Magisk Hide). Keep in mind that even after you reboot, modules will remain disabled, unless you re-enable them first. Also remember to re-enable Magisk Hide if you had it enabled before.
Please see @Didgeridoohan's guide for more details: https://www.didgeridoohan.com/magisk/MagiskModuleIssues#hn_Core_Only_Mode
It's also worth mentioning, his guide is extremely well-made and contains a lot of useful information that could benefit all Magisk users and modders. I highly recommend looking through it anyway!
I am getting an error with unpacking the boot image with both the one provided as well as the one direct from Google. Any fix?
@AlphAndroid, I had no problem with Google's boot img. Maybe you should download the factory image again and check the SHA-256 checksum to make sure the download is not corrupt.
@i5lee8bit, thanks for the guide as always, worked fine! Just adding that the platform tools have been updated to r31.0.2 from r31.0.0: https://developer.android.com/studio/releases/platform-tools
AlphAndroid said:
I am getting an error with unpacking the boot image with both the one provided as well as the one direct from Google. Any fix?
Click to expand...
Click to collapse
What do you mean with unpacking the boot image? Are you trying to patch it yourself in Magisk Manager and talking about the step where it says unpacking the boot image? @Ghisy's advice is good, check the hash checksums. Here are various hash checksums of the untouched factory boot image for this month:
File: coral-rq2a.210505.002-factory-boot.img
CRC-32: cedb0fab
MD5: 987f7849b32f3a652c7d8378bbe0048a
SHA-1: f55f0e4a3fc7d4e321a4f8fea0cad157f371f564
SHA-256: d2a53c9527b21f51526a4343506b2617c8b78100c3e6fb90df517372493145ba
SHA-512: 9a3c027b5fdc9072c7955b01be5489060f66ff718ddf51dcd1350324f84d56219f20086cd8ce128721246d6b88c08fbb0de6642d3dec60c141f2496f42316364
SHA3-256: 74fe9d3d65f6e186dfc0c7708f12b7f308e2f014720fc8930549c7d2c349aaef
SHA3-512: 48d3890a8e014ff65d4e81fdaa9f13746aa4ab9632f6e600cebb1e697bff45ebbe22b16b205965d31e8056667361f217ad29db6f9a0b9d44927bfb065cf82f0c
Are you downloading from PC and then copying to the phone? If you're using MTP or FTP, sometimes they mess with the file in tiny, almost unnoticeable (annoying) ways. Try downloading directly from the phone (and check the hash while you're at it).
i5lee8bit said:
What do you mean with unpacking the boot image? Are you trying to patch it yourself in Magisk Manager and talking about the step where it says unpacking the boot image? @Ghisy's advice is good, check the hash checksums. Here are various hash checksums of the untouched factory boot image for this month:
File: coral-rq2a.210505.002-factory-boot.img
CRC-32: cedb0fab
MD5: 987f7849b32f3a652c7d8378bbe0048a
SHA-1: f55f0e4a3fc7d4e321a4f8fea0cad157f371f564
SHA-256: d2a53c9527b21f51526a4343506b2617c8b78100c3e6fb90df517372493145ba
SHA-512: 9a3c027b5fdc9072c7955b01be5489060f66ff718ddf51dcd1350324f84d56219f20086cd8ce128721246d6b88c08fbb0de6642d3dec60c141f2496f42316364
SHA3-256: 74fe9d3d65f6e186dfc0c7708f12b7f308e2f014720fc8930549c7d2c349aaef
SHA3-512: 48d3890a8e014ff65d4e81fdaa9f13746aa4ab9632f6e600cebb1e697bff45ebbe22b16b205965d31e8056667361f217ad29db6f9a0b9d44927bfb065cf82f0c
Are you downloading from PC and then copying to the phone? If you're using MTP or FTP, sometimes they mess with the file in tiny, almost unnoticeable (annoying) ways. Try downloading directly from the phone (and check the hash while you're at it).
Click to expand...
Click to collapse
i also used a hash checksum, checked out the same
I'm just a bit hesitant to use the provided patched boot image now that I'm getting the issue.
I also had an error at 96% sideloading the OTA (something like: sideloading failed, no error 0). I then did NOTHING, stayed in Bootloader and downloaded the latest adb platform tools (mine was 30.0.5 from nov 2020, rather old) - with the newest platform tools I sideloaded again and then it worked (even though it stayed on 90% for 3-4 minutes, idk why, after that it smoothly went to 100% and finished sideloading) - then after that just normally flash the magisk patched file and the phone booted up again and is working fine. It seems to be more important than I thought to have the most up to date adb tools - never had an issue with that before. Thankfully my phone didnt go into bootloop, lol.
So it seems that the newest Pixel 4 xl OTA file is uncompatible with (maybe specific) older adb platform tools, ergo people if you have a problem, check your platform tools version - the OTA file that is linked here in this thread is fine and is not the rootcause of any issues.
Best place a remark into the mainpost @i5lee8bit that it is very important to keep the adb platform tools up to date and always check it before trying to update. It might save some people from trouble.
Hello all.
I need a little help please.
I am coming from:
10 (QQ2A.200305.003)
Magisk 21201 / 8.0.4
It’s been a while since I have done this and I would like to update to the Android 11 May version and I would like to make sure that what I am about to do is procedurally correct.
And, I am hoping this is the correct place to post
Download 11.0.0 (RQ2A.210505.002, May 2021 (coral-rq2a.210505.002-factory-0ec4212f.zip)
Unhide/Uninstall Magisk - Restore Images
Is this necessary with a factory reset?
Factory reset
Boot phone into fastboot mode
Flash-all.bat –w
At this point, once the phone re-boots, I should have a “working” phone on Android 11?
Extract boot.img and copy to phone
Download Magisk-v23.0.apk to phone and install
Do I set the update channel to beta or canary?
Install/select & patch boot.img
Reboot
Copy patched boot.img to computer
reboot into fastboot
Should I / could I fastboot flash boot boot.img --slot all at this point just to be safe?
Fastboot flash boot patchedboot.img
Fastboot reboot
Safetynet fix
Set update channel
Enjoy.
Am i missing anything?
Thanks in advance
ƒ

[GUIDE] Pixel 5 "redfin": Unlock Bootloader, Update, Root, Pass SafetyNet

If you are looking for my guide on a different Pixel, find it here:
Pixel 3
Pixel 3XL
Pixel 3a
Pixel 3aXL
Pixel 4
Pixel 4XL
Pixel 4a
Pixel 4a (5G)
Pixel 5a
Pixel 6
Pixel 6 Pro
For best results, use the latest stable Magisk release.
Discussion thread for migration to 24.0+.
Note: Magisk prior to Canary 23016 does not incorporate the necessary fixes for Android 12+.
WARNING: YOU AND YOU ALONE ARE RESPONSIBLE FOR ANYTHING THAT HAPPENS TO YOUR DEVICE. THIS GUIDE IS WRITTEN WITH THE EXPRESS ASSUMPTION THAT YOU ARE FAMILIAR WITH ADB, MAGISK, ANDROID, AND ROOT. IT IS YOUR RESPONSIBILITY TO ENSURE YOU KNOW WHAT YOU ARE DOING.
Prerequisites:
Latest SDK Platform Tools - if Platform Tools is out of date, you WILL run into problems!
USB Debugging enabled
Google USB Driver installed
I recommend using Command Prompt for these instructions; some users have difficulty with PowerShell.
Make sure the Command Prompt is running from your Platform Tools directory!
Android Source - Setting up a device for development
Spoiler: Downloads
Pixel OTA Images
Pixel Factory Images
Magisk Stable, Magisk Canary - Magisk GitHub
Spoiler: Unlock Bootloader
Follow these instructions to enable Developer Options and USB Debugging.
Enable OEM Unlocking. If this option is grayed out, unlocking the bootloader is not possible.
Connect your device to your PC, and open a command window in your Platform Tools folder.
Ensure ADB sees your device:
Code:
adb devices
If you don't see a device, make sure USB Debugging is enabled, reconnect the USB cable, or try a different USB cable.
If you see "unauthorized", you need to authorize the connection on your device.
If you see the device without "unauthorized", you're good to go.
Reboot to bootloader:
Code:
adb reboot bootloader
Unlock bootloader: THIS WILL WIPE YOUR DEVICE!
Code:
fastboot flashing unlock
Select Continue on the device screen.
Spoiler: Initial Root / Create Master Root Image
Install Magisk on your device.
Download the factory zip for your build.
Inside the factory zip is the update zip: "device-image-buildnumber.zip". Open this, and extract boot.img
Copy boot.img to your device.
Patch boot.img with Magisk: "Install" > "Select and Patch a File"
Copy the patched image back to your PC. It will be named "magisk_patched-23xxx_xxxxx.img". Rename this to "master root.img" and retain it for future updates.
Reboot your device to bootloader.
Flash the patched image:
Code:
fastboot flash boot <drag and drop master root.img here>
Reboot to Android. Open Magisk to confirm root - under Magisk at the top, you should see "Installed: <Magisk build number>
Spoiler: Update and Root Automatic OTA
Before you download the OTA, open Magisk, tap Uninstall, then Restore Images. If you have any Magisk modules that modify system, uninstall them now.
Take the OTA update when prompted. To check for updates manually, go to Settings > System > System Update > Check for Update
Allow the update to download and install. DO NOT REBOOT WHEN PROMPTED. Open Magisk, tap Install at the top, then Install to inactive slot. Magisk will then reboot your device.
You should now be updated with root.
Spoiler: Update and Root OTA Sideload
Download the OTA.
Reboot to recovery and sideload the OTA:
Code:
adb reboot sideload
Once in recovery:
Code:
adb sideload ota.zip
When the OTA completes, you will be in recovery mode. Select "Reboot to system now".
Allow system to boot and wait for the update to complete. You must let the system do this before proceeding.
Reboot to bootloader.
Boot the master root image (See note 1):
Code:
fastboot boot <drag and drop master root.img here>
Note: If you prefer, you can download the factory zip and manually patch the new boot image, then flash it after the update. Do not flash an older boot image after updating.
Your device should boot with root. Open Magisk, tap Install, and select Direct Install.
Reboot your device. You should now be updated with root.
Note: You can use Payload Dumper to extract the contents of the OTA if you want to manually patch the new boot image. However, I will not cover that in this guide.
Spoiler: Update and Root Factory Image
Please note that the factory update process expects an updated bootloader and radio. If these are not up to date, the update will fail.
Download the factory zip and extract the contents.
Reboot to bootloader.
Spoiler: Update bootloader if necessary
Compare bootloader versions between phone screen and bootloader.img build number
Code:
fastboot flash bootloader <drag and drop new bootloader.img here>
If bootloader is updated, reboot to bootloader.
Spoiler: Update radio if necessary
Compare baseband versions between phone screen and radio.img build number
Code:
fastboot flash radio <drag and drop radio.img here>
If radio is updated, reboot to bootloader.
Apply update:
Code:
fastboot update --skip-reboot image-codename-buildnumber.zip
When the update completes, the device will be in fastbootd. Reboot to bootloader.
Boot the master root image (See note 1):
Code:
fastboot boot <drag and drop master root.img here>
Note: If you prefer, you can manually patch the new boot image, then flash it after the update. Do not flash an older boot image after updating.
Your device should boot with root. Open Magisk, tap Install, and select Direct Install.
Reboot your device. You should now be updated with root.
Note: If you prefer, you can update using the flash-all script included in the factory zip. You will have to copy the script, bootloader image, radio image, and update zip into the Platform Tools folder; you will then have to edit the script to remove the -w option so it doesn't wipe your device.
The scripted commands should look like this:
Code:
fastboot flash bootloader <bootloader image name>
fastboot reboot bootloader
ping -n 5 127.0.0.1 > nul
fastboot flash radio <radio image name>
fastboot reboot bootloader
ping -n 5 127.0.0.1 > nul
fastboot update --skip-reboot <image-device-buildnumber.zip>
Once this completes, you can reboot to bootloader and either boot your master patched image, or if you patched the new image, flash it at this time.
Spoiler: Update and Root using PixelFlasher <<RECOMMENDED FOR NOVICES>>
PixelFlasher by @badabing2003 is an excellent tool that streamlines the update process - it even patches the boot image for you.
The application essentially automates the ADB interface to make updating and rooting much easier. However, it is STRONGLY recommended that you still learn the "basics" of using ADB.
For instructions, downloads, and support, please refer to the PixelFlasher thread.
Spoiler: Update and Root using the Android Flash Tool
Follow the instructions on the Android Flash Tool to update your device. Make sure Lock Bootloader and Wipe Device are UNCHECKED.
When the update completes, the device will be in fastbootd. Reboot to bootloader.
Boot the master root image (See note 1):
Code:
fastboot boot <drag and drop master root.img here>
Note: If you prefer, you can download the factory zip and manually patch the new boot image, then flash it after the update. Do not flash an older boot image after updating.
Your device should boot with root. Open Magisk, tap Install, and select Direct Install.
Reboot your device. You should now be updated with root.
Spoiler: Pass SafetyNet/Play Integrity
SafetyNet has been deprecated for the new Play Integrity API. More information here.
In a nutshell, Play Integrity uses the same mechanisms as SafetyNet for the BASIC and DEVICE verdicts, but uses the Trusted Execution Environment to validate those verdicts. TEE does not function on an unlocked bootloader, so legacy SafetyNet solutions will fail.
However, @Displax has modified the original Universal SafetyNet Fix by kdrag0n; his mod is able to force basic attestation instead of hardware, meaning that the device will pass BASIC and DEVICE integrity.
Mod available here. Do not use MagiskHide Props Config with this mod.
This is my configuration that is passing Safety Net. I will not provide instructions on how to accomplish this. Attempt at your own risk.
Zygisk + DenyList enabled
All subcomponents of these apps hidden under DenyList:
Google Play Store
GPay
Any banking/financial apps
Any DRM media apps
Modules:
Universal SafetyNet Fix 2.3.1 Mod - XDA post
To check SafetyNet status:
YASNAC - GitHub
To check Play Integrity status:
Play Integrity Checker - NOTE: MEETS_STRONG_INTEGRITY will ALWAYS fail on an unlocked bootloader.
I do not provide support for Magisk or modules. If you need help with Magisk, here is the Magisk General Support thread. For support specifically with Magisk v24+, see this thread.
Points of note:
The boot image is NOT the bootloader image. Do not confuse the two - YOU are expected to know the difference. Flashing the wrong image to bootloader could brick your device.
While the Magisk app is used for patching the boot image, the app and the patch are separate. This is what you should see in Magisk for functioning root:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
"Installed" shows the version of patch in the boot image. If this says N/A, you do not have root access - the boot image is not patched, or you have a problem with Magisk.
"App" simply shows the version of the app itself.
If you do not have a patched master boot image, you will need to download the factory zip if you haven't already, extract the system update inside it, then patch boot.img.
If you prefer updating with the factory image, you can also extract and manually patch the boot image if desired.
Some Magisk modules, especially those that modify read only partitions like /system, may cause a boot loop after updating. As a general rule, disable these modules before updating. You are responsible for knowing what you have installed, and what modules to disable.
Credits:
Thanks to @badabing2003 , @pndwal , @Displax , @Az Biker , @ipdev , @kdrag0n , @Didgeridoohan , and last but not least, @topjohnwu for all their hard work!
V0latyle said:
As many of you know by now, in order to run a patched boot image on Android 12 requires disabling Android Boot Verification.
On Android 12, disabling verity and verification will require a data wipe if it hasn't been done before. What seems to "lock" the state of boot verification is booting into system; so, if you perform an update, or flash vbmeta without the disable flags, then reboot into Android, you have essentially enabled boot verification and will require a wipe to disable it again. Confusing, I know.
Here is the appropriate update process. DO NOT take the automatic OTA if you are rooted. If you allow the phone to reboot after an update without disabling boot verification, you will have to wipe in order to disable it again, as you would need to for a patched boot image.
***Note***: The boot image doesn't have to be patched before you perform the update. Some have found it works better to update, THEN patch the boot image.
OTA Sideload:
1. Download both the OTA and the factory zip.
2. Extract vbmeta.img and boot.img from the factory zip.
3. Patch the boot image and copy it back to your computer.
4. Reboot to recovery and sideload the OTA: select Apply Update via ADB, then on your PC:
Code:
adb sideload ota.zip
5. When the OTA completes, you will be in recovery mode. DO NOT REBOOT TO SYSTEM. Select "Reboot to bootloader".
6. Reflash vbmeta to disable boot verification:
Code:
fastboot flash vbmeta --disable-verity --disable-verification --slot=all vbmeta.img
7. Flash patched boot image:
Code:
fastboot flash boot --slot=all magisk_patched-23xxx_xxxxx.img
8. Reboot to system.
Factory update:
1. Download the factory zip.
2. Extract boot.img
3. Patch the boot image and copy it back to your computer.
4. Reboot to bootloader.
5. Apply update:
Code:
fastboot update --disable-verity --disable-verification --skip-reboot image-codename-buildnumber.zip
6. Flash patched boot image:
Code:
fastboot flash boot --slot=all magisk_patched-23xxx_xxxxx.img
7. Reboot to system.
Android Flash Tool:
1. Download the factory zip.
2. Extract boot.img
3. Patch the boot image and copy it back to your computer.
4. Reboot to bootloader.
5. Follow the instructions on the Android Flash Tool to update your device. The ONLY boxes you should check are "Disable Verity" and "Disable Verification"
6. When the update completes, the phone will reboot to system without root.
7. Reboot to bootloader and flash patched boot image:
Code:
fastboot flash boot --slot=all magisk_patched-23xxx_xxxxx.img
8. Reboot to system.
REMEMBER: The most critical part of this is making sure verity and verification are disabled during the update process before the phone reboots. If you forget to patch the boot image, that's OK - you don't have to flash /boot right after update.
If you have trouble with the patched boot image, simply flash /boot back to stock and allow Android to boot, then re-patch and re-flash the boot image.
You can also, if you want, boot the patched image instead of flashing it:
Code:
fastboot boot magisk_patched-23xxx_xxxxx.img
This is considered "temporary boot" as it loads the image from your PC rather than from device storage. You can use this to confirm root works, and if you so desire, you can then perform Direct Install in Magisk.
Click to expand...
Click to collapse
You Sir are all over these forums spreading helpful advice, and knowledge. I would just like to say Thank You for all you do here. It's so greatly appreciated. You are one of the many people who make this place so special.
Also, Thank You for your service to our country.
@V0latyle can you link me to a web page that would list every adb and fastboot command that we as android modders would use. What I mean is I couldn't find a Google search that listed the fastboot command with --slot=all among other adb and fastboot commands
Krsmqn said:
You Sir are all over these forums spreading helpful advice, and knowledge. I would just like to say Thank You for all you do here. It's so greatly appreciated. You are one of the many people who make this place so special.
Also, Thank You for your service to our country.
Click to expand...
Click to collapse
I agree with @Krsmqn, @V0latyle THANK YOU FOR YOUR SERVICE !!!!! in the military and for your service in the xda community
I used the Android Flash Tool method to update to the November build, and followed the instructions precisely. It worked flawlessly. My deny list is exactly the same in Magisk, and all my modules are working perfectly. I didn't even have to disable them. I think I will use this method from now on.
Krsmqn said:
You Sir are all over these forums spreading helpful advice, and knowledge. I would just like to say Thank You for all you do here. It's so greatly appreciated. You are one of the many people who make this place so special.
Also, Thank You for your service to our country.
Click to expand...
Click to collapse
elong7681 said:
I agree with @Krsmqn, @V0latyle THANK YOU FOR YOUR SERVICE !!!!! in the military and for your service in the xda community
Click to expand...
Click to collapse
Thanks guys, I appreciate it.
elong7681 said:
@V0latyle can you link me to a web page that would list every adb and fastboot command that we as android modders would use. What I mean is I couldn't find a Google search that listed the fastboot command with --slot=all among other adb and fastboot commands
Click to expand...
Click to collapse
Boy, I wish I had that handy, because I could sure use it too! I don't have your answer but hopefully someone else does, because believe me I'll be bookmarking it!
Will this work on Android Pixel 5a?
Rafiul Bari Chowdhury said:
Will this work on Android Pixel 5a?
Click to expand...
Click to collapse
Yes. The root process is exactly the same for the 4a 5g, 5, and 5a. The update process is the same across all Pixel devices.
I patched the boot.img. Magisk 23 did not report errors. But size of the patched file is zero. This looks not promising...
nostromo12 said:
I patched the boot.img. Magisk 23 did not report errors. But size of the patched file is zero. This looks not promising...
Click to expand...
Click to collapse
What version of Magisk did you use?
The stabil one
Will this work on Android Pixel 5a?
V0latyle said:
Yes. The root process is exactly the same for the 4a 5g, 5, and 5a. The update process is the same across all Pixel devices.
Click to expand...
Click to collapse
Okay. But Should I Remove Magisk Fully before upgrading through ADB/Fastboot/AFT?
H,
I'm on Android 11 pixel 5, can I use this tutorial ?
I think it's safer to unroot/remove Magisk and modules when going from 11 to 12 right? Some modules might not be compatible with 12 causing bootloops.
thecompany said:
I think it's safer to unroot/remove Magisk and modules when going from 11 to 12 right? Some modules might not be compatible with 12 causing bootloops.
Click to expand...
Click to collapse
You're going to have to wipe /data anyway if you intend to root on Android 12. Unless you're willing to try an idea I have.
Thanks V0latyle !!
I follow the flash tool method for update from october to november on my pixel 5
Perfect update, no issues and all data ok
nico22320 said:
Thanks V0latyle !!
I follow the flash tool method for update from october to november on my pixel 5
Perfect update, no issues and all data ok
Click to expand...
Click to collapse
Did you use Magisk canary? It is not necessary to check wipe in the android flash tool?
I use standard Magisk and can not change the update path to canary
nostromo12 said:
Did you use Magisk canary? It is not necessary to check wipe in the android flash tool?
I use standard Magisk and can not change the update path to canary
Click to expand...
Click to collapse
No i use the beta version of magisk.
You need wipe only for update from Android 11 to Android 12.
Just follow the guide for update to november and enjoy
nico22320 said:
No i use the beta version of magisk.
You need wipe only for update from Android 11 to Android 12.
Just follow the guide for update to november and enjoy
Click to expand...
Click to collapse
I want to upgrade from 11 (oktober) to 12
In the first message from this thread concerning the flash tool there was no wipe mentioned.
I want to update keeping my data ! How to proceed?
The best way: save yours photos etc with your Google account and make a fresh install with Factory image on Android 12 ( with disable verity and vérification)
It's long for set up device but 100% of chance of work with no issues for futurs update
Sûre you Can try to update without wipe and disable verity and vérification but maybe bootloops or not

How To Guide [Pixel 7 Pro] [TD1A.220804.031] Root guide + Extracted Images + How to

How to root:
You have two options for this, 1 is the recommended way and 2 is the lazy but works way.
Option 1 (RECOMMENDED):
Download the latest factory image from: https://developers.google.com/android/images#cheetah (at the time of writing this, it's TD1A.220804.031
Unlock bootloader (If you don't know how to do this, do not proceed further)
From the downloaded image file, extract the init_boot.img file and copy it to your phone (directory shouldn't matter)
Install the Magisk apk from: https://raw.githubusercontent.com/topjohnwu/magisk-files/canary/app-release.apk
Launch the app, select install, patch a file, select the init_boot file you placed in your phone
After it's done, it should place a file in your phone's download folder called magisk_patched-<VERSION>_<XYXYXYXYXY>.img
Copy that over to your PC and now boot to bootloader
Run the following commands from Powershell/commandline:
Code:
fastboot flash init_boot magisk_init_patched-25205_EfWOu.img
And then reboot, you'll be rooted
Option 2 (LAZY BUT WORKS):
I'm sharing my magisk patched init_boot from the TD1A.220804.031 build (post 73MB update). Instructions are:
Unlock bootloader (If you don't know how to do this, do not proceed further)
Boot to bootloader
Download the patched init_boot from: https://sourceforge.net/projects/ag.../magisk_init_patched-25205_EfWOu.img/download
Run the following commands from Powershell/commandline:
Code:
fastboot flash init_boot magisk_init_patched-25205_EfWOu.img
And then reboot, you'll be rooted
Install Magisk apk from here: https://raw.githubusercontent.com/topjohnwu/magisk-files/canary/app-release.apk
To get SafteyNet working:
Open the Magisk app
Open the settings from top right, Enable Zygisk
Reboot
Flash the MODIFIED SafteyNet fix module by @kdrag0n from the attached files on this thread from within Magisk Modules
Clear Play store data and you should be good!
Voila!
FASTBOOT IMAGES:
I'm sharing the stock extracted images of the TD1A.220804.031 build, should be a good reset point from fastboot incase any of you get stuck somehwere:
DO NOT MIRROR THIS PLEASE!!!!
VERIFY THE MD5 OF THE FILE AFTER DOWNLOADING!!!!!!!
Mirror 1 | Mirror 2
MD5: 43613f520697722840ded6a15eb27459
Massive shoutout to @Some_Random_Username for Mirror 1 and @akhilnarang for Mirror 2 since SourceForge was facing issues!
Now documentation on how to do it yourself (which I'd highly recommend since you should never trust any file given, always try to do it yourself!):
How to dump your own device:
1. Download a GSI which is userdebug/eng and equal/newer Security Patch of the current build on your device from any of the unofficial community builds here: https://github.com/phhusson/treble_experimentations/wiki/Generic-System-Image-(GSI)-list
2. Install the DSU Sideloader app from: https://github.com/VegaBobo/DSU-Sideloader/releases/latest
3. Follow instructions in the DSU sideloader app readme here: https://github.com/VegaBobo/DSU-Sideloader/blob/master/README.md
I'd recommend enabling the userdata toggle and typing 32GB as the size
4. Reboot into the DSU from the notification
5. When the device boots up, type the following in the terminal:
Code:
adb root
adb shell
mkdir -p /sdcard/dump
for file in /dev/block/bootdevice/by-name/*; do
if [ "${file##*/}" != "userdata" ]
then
echo Dumping "${file##*/}"
dd if=$file of=/sdcard/dump/"${file##*/}".img
fi
done
6. Once the dump is done, you'll have files in /sdcard/dump/
7. Copy those over to a PC
8. Voila
A massive thanks to @AndyYan @Some_Random_Username for their help (well hand holding) throughout the entire process <3
Also thanks to @OmkarTheAndroid for the re-brush up of the Android basics I forgot
Reserved
Thanks!
Have you had any luck with SafetyNet yet? People on another thread are saying that even the Modded version by @Displax isn't working on P7P with Canary Magisk
I'd like to remind all that, 1) the DSU method requires some Android/shell knowledge to correctly carry out, and 2) you're discouraged from actually flashing/using those GSIs (TD-based Android 13 GSIs are still in early phase, and P7/P will almost certainly get proper, fully functional device-specific ROMs shortly anyway).
Thanks for the dump! Could you maybe mirror it yourself to be sure? At least until Google's facory images are up Sourceforge is incredibly slow for me (and probably for others too).
so looks like vendor_dlkm has been replaced by vendor_kernel_boot and the init_boot is just the first-stage init. This will be interesting moving forward with AVB and custom images. I will start working on something when source drops. I will likely need to have some testers to see how much this requires to get a custom image up and running.
EDIT: vendor_boot is actually the one that has been separated out a bit between vendor_boot (holding modules) and vendor_kernel_boot, which has some ramdisk stuff like the vendor_boot has on Pixel 6 devices.
Kernel now consists of 6 images. init_boot, vendor_boot, vendor_kernel_boot, vendor_dlkm, dtbo and boot.img
I downloaded the init_boot.img file then got a big problem bricked my pixel 7 oro
mrteii1 said:
I downloaded the init_boot.img file then got a big problem bricked my pixel 7 oro
Click to expand...
Click to collapse
this is a soft brick, just flash the correct partition back using the stock image
Tahnks forbyour reply. How to get the stock image? Now it brickes. Im panicking
I think i'll hold fire on rooting until things are a little clearer. unlocking the bootloader in the usual fashion should be ok tho right?
whatsisnametake2 said:
I think i'll hold fire on rooting until things are a little clearer. unlocking the bootloader in the usual fashion should be ok tho right?
Click to expand...
Click to collapse
Yes, unlocking the bootloader is still the same and will wipe data.
Current SafetyNet Status (with modded universal SafetyNet Fix + Magisk Props):
Play Integrity API Checker:
MEETS_DEVICE_INTEGRITY: fail
MEETS_BASIC_INTEGRITY: pass
MEETS_STRONG_INTEGRITY: fail
YASNAC:
Basic integrity: pass
CTS profile match: fail
Edit: GPay does work on the Pixel Watch, even though it doesn't on the phone (when rooted).
Make sure to add your cards there if you're using the Pixel Watch and can't use GPay on your phone.
zetsumeikuro said:
Yes, unlocking the bootloader is still the same and will wipe data.
Click to expand...
Click to collapse
If you can boot to recovery try a factory reset from there or you will have to power it off and wait until Google releases the image.
mrteii1 said:
Tahnks forbyour reply. How to get the stock image? Now it brickes. Im panicking
Click to expand...
Click to collapse
In the OP, the part with:
"FASTBOOT IMAGES:
I'm sharing the stock extracted images of the TD1A.220804.031 build, should be a good reset point from fastboot incase any of you get stuck somehwere:
DO NOT MIRROR THIS PLEASE!!!!"
Misterxtc said:
If you can boot to recovery try a factory reset from there or you will have to power it off and wait until Google releases the image.
Click to expand...
Click to collapse
? unlocking is just going to do a data wipe/factory reset anyway. not sure why I would need the factory image for that? or to do an additional factory reset from recovery?
Misterxtc said:
If you can boot to recovery try a factory reset from there or you will have to power it off and wait until Google releases the image.
Click to expand...
Click to collapse
Maybe you replied to the wrong user?
Hey everyone, a slight update on the website for the image dump, SourceForge was giving people incomplete files so @Some_Random_Username is generously hosting it on his servers <3
please verify the MD5 of the downloaded zip before trying to modify any parititons using the following commands:
On windows:
Code:
certutil -hashfile cheetah-TD1A.220804.031-compressed.zip MD5
On Linux/MacOS:
Code:
md5sum cheetah-TD1A.220804.031-compressed.zip
The MD5 should be: 43613f520697722840ded6a15eb27459
whatsisnametake2 said:
? unlocking is just going to do a data wipe/factory reset anyway. not sure why I would need the factory image for that? or to do an additional factory reset from recovery?
Click to expand...
Click to collapse
I was thinking the reset would force it to boot off the other slot.

Categories

Resources