Question Can't update to Dec OTA [SOLVED] - Google Pixel 7

Hey, I followed this tutorial https://www.xda-developers.com/how-to-install-ota-updates-keep-root-google-pixel-phone/ (recommended method) and I'm not getting results. After flashing the original boot img, etc. my update screen says my device is updated so I'm not getting Dec. OTA.
I tried also with the Uninstall Magisk (restore images) method and I'm getting the same results, not OTA available.
I'm doing it with all modules disabled.
What am I missing?

alsansan said:
Hey, I followed this tutorial https://www.xda-developers.com/how-to-install-ota-updates-keep-root-google-pixel-phone/ (recommended method) and I'm not getting results. After flashing the original boot img, etc. my update screen says my device is updated so I'm not getting Dec. OTA.
I tried also with the Uninstall Magisk (restore images) method and I'm getting the same results, not OTA available.
I'm doing it with all modules disabled.
What am I missing?
Click to expand...
Click to collapse
You may have to wait for the update over the internet, then once it starts there's more waiting for the installation to complete, plus you could end up with a "problem" error after everything seemed fine during the first 20 minutes. OTA updates will be less frustrating and faster using adb to sideload over USB.
This guide for Pixel 6 is a good reference for most Pixel 7 situations (the main difference with 7 is to patch, flash or restore init_boot.img instead of boot.img).

alsansan said:
Hey, I followed this tutorial https://www.xda-developers.com/how-to-install-ota-updates-keep-root-google-pixel-phone/ (recommended method) and I'm not getting results. After flashing the original boot img, etc. my update screen says my device is updated so I'm not getting Dec. OTA.
I tried also with the Uninstall Magisk (restore images) method and I'm getting the same results, not OTA available.
I'm doing it with all modules disabled.
What am I missing?
Click to expand...
Click to collapse
If it helps..
I just happened to use my P7 as an example in a different thread.
[Discussion] Magisk - The Age of Zygisk - Post # 2,648​
Includes a Github link showing the modification to the flash-all script I use.
Includes a Pastbin link showing my update from Nov -> Dec.
Cheers.
PS.
Just to be clear, I (always) use full factory images for Pixel updates.
- Factory Images for Nexus and Pixel Devices
Not the incremental OTA(s).
- Full OTA Images for Nexus and Pixel Devices

manjaroid said:
You may have to wait for the update over the internet, then once it starts there's more waiting for the installation to complete, plus you could end up with a "problem" error after everything seemed fine during the first 20 minutes. OTA updates will be less frustrating and faster using adb to sideload over USB.
This guide for Pixel 6 is a good reference for most Pixel 7 situations (the main difference with 7 is to patch, flash or restore init_boot.img instead of boot.img).
Click to expand...
Click to collapse
Thanks, I want to try the adb to sideload method, but I have doubts. it is technically detrimental to update flashing factory image / ota over the previous factory image? It's been years since my last rooted phone and I remember people suggested not to do this (I think they recommended full wipe), but I don't know how it goes today.

ipdev said:
If it helps..
Click to expand...
Click to collapse
Helps me! Learned some new stuff and added it to my notes.

alsansan said:
Thanks, I want to try the adb to sideload method, but I have doubts. it is technically detrimental to update flashing factory image / ota over the previous factory image? It's been years since my last rooted phone and I remember people suggested not to do this (I think they recommended full wipe), but I don't know how it goes today.
Click to expand...
Click to collapse
Flashing the OTA doesn't wipe but factory will wipe if you run flash-all (.bat for Windows, .sh for Linux) without removing the -w argument on the fastboot line. i.e., Flashing the OTA will get you updated without losing anything but flashing factory is preferable for updates as long as wiping is disabled.
The factory zip is what PixelFlasher uses for non-destructive updates without having to uninstall Magisk. It's the easiest way to update a rooted Pixel, but mistakes still happen. Like its developer recommends, best to tackle command line methods before jumping into GUI methods.
As far as detrimental flashing goes, with Pixels and stock firmware you would have to stray far off the trail to break the phone.

manjaroid said:
Flashing the OTA doesn't wipe but factory will wipe if you run flash-all (.bat for Windows, .sh for Linux) without removing the -w argument on the fastboot line. i.e., Flashing the OTA will get you updated without losing anything but flashing factory is preferable for updates as long as wiping is disabled.
The factory zip is what PixelFlasher uses for non-destructive updates without having to uninstall Magisk. It's the easiest way to update a rooted Pixel, but mistakes still happen. Like its developer recommends, best to tackle command line methods before jumping into GUI methods.
As far as detrimental flashing goes, with Pixels and stock firmware you would have to stray far off the trail to break the phone.
Click to expand...
Click to collapse
Thank you manjaroid! Finally I updated flashing the Dec factory image with flash-all.bat script (-w removed) and rerooted with the new patched init_boot.img it's really easy but we have doubts the first time. You answered my question (flashing factory is preferable for updates), but why is that? I want to understand a little bit more. And whats the difference between an destructive/non-destructive update?

alsansan said:
...You answered my question (flashing factory is preferable for updates), but why is that? I want to understand a little bit more.
Click to expand...
Click to collapse
How I might explain it is OTA's are incremental updates that patch specific particular parts of the system. You might want to look at it like in an instance of laying a foundation/base, OTA's would be like replacing cracked/broken/weak sections with bricks. As time goes on and more OTA's are released and patched, more of the foundation is put together by more and more bricks -- which may be (quick and easy) or may not be (not a single solid base/structure) more detrimental as time progresses (cumulative patches may inadvertently cause glitches/bugs down the road vs. a full factory [non-patch] update). While holding up upon that patchworks of bricks among the "foundation" is perfectly serviceable and can well enough hold up whatever structure is placed on it, having a whole piece unpatched foundation (Full Factory image) is still preferable as a base/foundation because implementing that "foundation" (versus a foundation with various patchworks in it [OTA's]) would include in itself whatever fix/reinforcement the bricks patched(cracked/broken/weak sections) [what the OTA's did] while establishing a complete whole unseparated-in-any-place base/foundation.
So, in the end, it's preferable to have a solid, whole, almost from-scratch Full Factory image firmware update than a circumstance of patching upon patching the way OTA's implement their updates.
Also, unless you update the device by OTA's from the OS and it's as simple as that (although it can take pretty long; upwards to seemingly 20 minutes) -- because you have an locked bootloader -- the only other way to install an OTA is sideloading it which means you have to download it to a computer, boot up the device in a certain way, and run a command on the computer; which is very similar and not too much different than what you would do if updating using a Full Factory image anyway -- download image (Full Factory instead of OTA), load up device in a certain way (bootloader/fastboot mode instead of recovery) and run a command (flash-all.bat instead of adb sideload .zip); one major difference is you must edit the flash-all.bat script so it doesn't delete user data and factory reset the device.
Sorry for the long explanation, but that is why IMHO it is more preferable to update using the Full Factory image than OTA...

alsansan said:
whats the difference between an destructive/non-destructive update?
Click to expand...
Click to collapse
Not a good choice of words ("non-destructive updates"). That's kinda redundant since most of us don't intend to lose anything when updating. fastboot has to be told to wipe or not so calling it non-destructive flashing would have made better sense.

Related

Nexus 7 3G - 4.2.1 OTA Update for Custom Recovery

Ok, so there seems to be some issues with installing the recent 4.2.1 OTA update with custom recoveries (ie: CWM or TWRP). I ran into this issue myself, and I've seen many other posts with similar problems. I've found the solution and explained it in multiple threads, but due to the nature of the issue, I thought it deserved it's own thread to make sure everyone is aware of the problem and the workaround.
Details:
The 4.2.1 OTA update comes in two flavors - nakasi and nakasig. The former is for WiFi devices (8, 16, 32), and the latter is for 3G devices. In turn, they each have their own device types - grouper and talapia, respectively. While the hardware differences between the WiFi and 3G models is negligible, and most things are interchangeable (ie: kernels, recoveries, etc.), the updates are NOT, and you need to pick the correct one for your platform. For the 3G models, this means the 'nakasig' version.
However, the first thing the OTA update does is validate the integrity of the system. In addition to checking about 200 files in the /system partition, it also looks at the device itself. Specifically:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2/JOP40C/527662:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2.1/JOP40D/533553:user/release-keys");
assert(getprop("ro.product.device") == "talapia" ||
getprop("ro.build.product") == "talapia");
While the first part checks the build.prop file to see what the "ro.build.fingerprint" has defined, the latter (bolded) assert examines what the RECOVERY says the system is. This is where the problem lies. AFAIK, there are no 'talipia' versions of CWM or TWRP. All 3G users running custom recoveries are using the 'grouper' (ie: Wi-Fi only) version. And this is fine 99% of the time. But this is the 1% of the time when they are not compatible. As a result, when the updater script checks recovery, and is told that the system is 'grouper', it aborts the update.
I ran into this issue on both the latest versions of TWRP and CWM. I wasn't sure why, since I thought it just looked at build.prop which was OK. After speaking with oldblue910, he explained that it is getting that information not from build.prop, but from the custom recovery, which is why the update was failing (thanks to oldblue910 for the info!).
SO, I was left with one of two options. I could either restore the stock talipia recovery or modify the update zip to ignore this information. I chose the latter. I'm not sure why Google decided to even but this redundant check in place, since the build.prop fingerprint check should suffice to validate the hardware. Not to mention that the next part of the update is to assert check the majority of files in 'system' anyway, which would fail if it wasn't a 3G device. In any case, by removing the above bolded lines out of the updater-script, my tablet was able to be successfully updated to 4.2.1.
Since many other XDA users run custom recoveries, it is safe to say many other users will run into this issue as well. So I put my custom update online for anyone else to use.
You can download it here:
http://core.routed.com/CUSTOM_RECOVERY-65880f56b1c0.signed-nakasig-JOP40D-from-JOP40C.65880f56.zip
MD5SUM: b0adff6a04ca2ca6234a9678476d329e
A couple notes:
1) This update zip is completely identical to the Google version, outside of the talipia check removed.
2) This update should ONLY BE USED ON 3G NEXUS 7 MODELS. It will NOT work on Wi-Fi only versions.
3) All the other asserts are left in-tact, as they should be. So your 'system' needs to be mostly stock. It checks and patches about 200 files, and if any of them are modified, removed, frozen, etc., the update will fail.
4) The OTA update does NOT check or update the bootloader or kernel, so modifications or non-4.2-stock versions in those areas are fine. However, as stated in #3, mostly everything else should be stock.
5) If the update fails on a specific assert, it will explain what the problem is (ie: the specific apk or odex file). You will need to fix that before proceeding. If you run into an issue and require assistance, you will need to explain the exact error message.
6) As this is almost completely stock OTA update, you WILL lose root/custom recovery unless you take precautions to prevent them from being overwritten. To preserve root, you can use RootKeeper or a similar app to back it up. The latest version of CWM also will warn you if root is lost and apparently restore it for you. For the recovery side of things, the update puts that recovery-recovery file on the system. You can either manually remove it via adb shell (BEFORE REBOOTING AFTER THE UPDATE), or in CWM (and possibly TWRP's case), it should warn you that you might lose custom recovery after the update and ask if you want it to fix it for you (say yes).
Hopefully this helps others who ran into the same error as me. Enjoy!
phonic said:
Ok, so there seems to be some issues with installing the recent 4.2.1 OTA update with custom recoveries (ie: CWM or TWRP). I ran into this issue myself, and I've seen many other posts with similar problems. I've found the solution and explained it in multiple threads, but due to the nature of the issue, I thought it deserved it's own thread to make sure everyone is aware of the problem and the workaround.
Details:
The 4.2.1 OTA update comes in two flavors - nakasi and nakasig. The former is for WiFi devices (8, 16, 32), and the latter is for 3G devices. In turn, they each have their own device types - grouper and talapia, respectively. While the hardware differences between the WiFi and 3G models is negligible, and most things are interchangeable (ie: kernels, recoveries, etc.), the updates are NOT, and you need to pick the correct one for your platform. For the 3G models, this means the 'nakasig' version.
However, the first thing the OTA update does is validate the integrity of the system. In addition to checking about 200 files in the /system partition, it also looks at the device itself. Specifically:
assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2/JOP40C/527662:user/release-keys" ||
file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/nakasig/tilapia:4.2.1/JOP40D/533553:user/release-keys");
assert(getprop("ro.product.device") == "talapia" ||
getprop("ro.build.product") == "talapia");
While the first part checks the build.prop file to see what the "ro.build.fingerprint" has defined, the latter (bolded) assert examines what the RECOVERY says the system is. This is where the problem lies. AFAIK, there are no 'talipia' versions of CWM or TWRP. All 3G users running custom recoveries are using the 'grouper' (ie: Wi-Fi only) version. And this is fine 99% of the time. But this is the 1% of the time when they are not compatible. As a result, when the updater script checks recovery, and is told that the system is 'grouper', it aborts the update.
I ran into this issue on both the latest versions of TWRP and CWM. I wasn't sure why, since I thought it just looked at build.prop which was OK. After speaking with oldblue910, he explained that it is getting that information not from build.prop, but from the custom recovery, which is why the update was failing (thanks to oldblue910 for the info!).
SO, I was left with one of two options. I could either restore the stock talipia recovery or modify the update zip to ignore this information. I chose the latter. I'm not sure why Google decided to even but this redundant check in place, since the build.prop fingerprint check should suffice to validate the hardware. Not to mention that the next part of the update is to assert check the majority of files in 'system' anyway, which would fail if it wasn't a 3G device. In any case, by removing the above bolded lines out of the updater-script, my tablet was able to be successfully updated to 4.2.1.
Since many other XDA users run custom recoveries, it is safe to say many other users will run into this issue as well. So I put my custom update online for anyone else to use.
You can download it here:
http://core.routed.com/CUSTOM_RECOVERY-65880f56b1c0.signed-nakasig-JOP40D-from-JOP40C.65880f56.zip
MD5SUM: b0adff6a04ca2ca6234a9678476d329e
A couple notes:
1) This update zip is completely identical to the Google version, outside of the talipia check removed.
2) This update should ONLY BE USED ON 3G NEXUS 7 MODELS. It will NOT work on Wi-Fi only versions.
3) All the other asserts are left in-tact, as they should be. So your 'system' needs to be mostly stock. It checks and patches about 200 files, and if any of them are modified, removed, frozen, etc., the update will fail.
4) The OTA update does NOT check or update the bootloader or kernel, so modifications or non-4.2-stock versions in those areas are fine. However, as stated in #3, mostly everything else should be stock.
5) If the update fails on a specific assert, it will explain what the problem is (ie: the specific apk or odex file). You will need to fix that before proceeding. If you run into an issue and require assistance, you will need to explain the exact error message.
6) As this is almost completely stock OTA update, you WILL lose root/custom recovery unless you take precautions to prevent them from being overwritten. To preserve root, you can use RootKeeper or a similar app to back it up. The latest version of CWM also will warn you if root is lost and apparently restore it for you. For the recovery side of things, the update puts that recovery-recovery file on the system. You can either manually remove it via adb shell (BEFORE REBOOTING AFTER THE UPDATE), or in CWM (and possibly TWRP's case), it should warn you that you might lose custom recovery after the update and ask if you want it to fix it for you (say yes).
Hopefully this helps others who ran into the same error as me. Enjoy!
Click to expand...
Click to collapse
I compiled a CWM image for tilapia, so now users can flash updates and roms for their device without trying to by-pass the safety checks. With everyone recommending flashing grouper recovery, people are going to keep flashing grouper roms and wonder why things aren't working correctly.
The two devices differ in more respects than a simple assert check, including having different recovery.fstab files, which are used to make and configure recovery.
Better to have proper recovery for our (unique) device instead of a grouper port. The CWM image is not touch, the touch sources are not open source and koush's online builder is not producing a working image at this time. I ported one by hand, but it is too buggy to release.
I'll add twrp to the post sometime later.
mateorod said:
I compiled a CWM image for tilapia, so now users can flash updates and roms for their device without trying to by-pass the safety checks. With everyone recommending flashing grouper recovery, people are going to keep flashing grouper roms and wonder why things aren't working correctly.
Better to have proper recovery for our (unique) device instead of a grouper port. The CWM image is not touch, the touch sources are not open source and koush's online builder is not producing a working image at this time. I ported one by hand, but it is too buggy to release.
I'll add twrp to the post sometime later.
Click to expand...
Click to collapse
Thanks, that's definitely a better solution versus a work around.
Though the safety check bypassed in the OP wouldn't cause any issues since it was redundant and unnecessary. The OTA update already checks build.prop for the model info and all the apks/odexes it updates, so it would be impossible to flash it on a non-compatible device. But you raise a very valid point about incorrect ROMs and other things. The 3G unit probably needs it's own forum.
Did you have to make any real modifications to CWM outside of changing grouper to talapia?
The 3G unit probably needs it's own forum.
Click to expand...
Click to collapse
Its already done here; http://forum.xda-developers.com/forumdisplay.php?f=2022
Ather said:
Its already done here; http://forum.xda-developers.com/forumdisplay.php?f=2022
Click to expand...
Click to collapse
Woohoo! Thanks.
I had some issues when I did the update. It gave me some errors, and aborted, but then I found a link that had the update and I got it to update. This happened on my n4 and n73g. Well, for some reason, the recoveries got deleted so I had to reinstall them. I was able to use the goo manager to restore TWRP on my N4, but it wasn't working on my N7 so I had to side load it. After this, I noticed that google now wasn't working on my n4, and the volume rocker on my n7 had some issues. I went in and wiped the cache and dalvik cache and rebooted. Google now works on my N4, and while the volume gets adjusted on my N7, it won't make the beep every time I push up or down on the rocker indicating the volume level. I haven't noticed any other issues, but I haven't really delved into my devices. I may try to do a factory wipe and return everything to stock just to see what went wrong in the first place and to see if I can do anything different I still can't figure out how to get ADB running on my computer, so yes I used one of the tool kits to load everything. I know the OP's position on tool kits, but I just can't figure out how to get ADB running manually, AND it takes so long to download and install everything unless I am installing things I don't even need.
Nexus 7 takju firmware update
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Do you have the Galaxy Nexus or Nexus 7? If Galaxy Nexus, you of course would want to check those forums. As for the updates, you should normally see a notification alerting you of the update, but you can also check for it in settings/about phone/system updates. Otherwise the appropriate forum for your device will have links to the update files. Good luck!
lil help please
I updated to 4.2.1 with the OTA zip file using TWRP and voodoo root keeper installed. It flashed just fine. Rebooted with update. My root access is funky though. SuperSU is still there and I can access root file threw root explorer but I can't mount it as writable and when I install a new app that needs root access it never asks for it. Does superSU need to be updated? There is no update available for it.
Vlad7777 said:
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Click to expand...
Click to collapse
Is your device rooted? Is this your first android device? You will get a little notification in the notification bar at the top saying your deivce has an update.. If you have not rooted, you will receive the first OTA in a day or two that will go from JVP15S to JOP40C. Then later, you will receive the update for JOP40D. Some people have had success at forcing the update by going to settings, apps, all, google framework services, and selecting force stop then clearing the data. You then go back into settings, about device, check for updates and check for update.
Vlad7777 said:
Hi, while this is a very detailed description, I am still in need of help.
I just got a Google Nexus 7 from Google play store and it came with JVP15S firmware.
I understand that this is takju version of th edevice - I would like to upgrade it with the latest firmware but going through all the posts, I am totally lost.
I see upgrade files to upgrade from JOP40C to JOP40D - and see al ldifferent update combinations - but cannot fined one for JVP15S to JOP40D.
Also, all the updates are for different version "tilapia" and other fishes -- but none for takju (whatever that means)
Can someone direct me to right place to get the right updates/
Also I see a lot of posts and articles stating that Google is "pushing" the 4.2.1 Firmware JOP40D to Nexus 7 devices - how is this "pushing" manifest itself? What is the procedure for OTA update? Do I need to go to a place on Google to get it? Is it supposed to be downloaded automatically?
Hope someone can help.
Click to expand...
Click to collapse
The N73G ships with an interim 4.2 build, which is JVP15S. There are some significant differences between this and JOP40C, which is the first update you will get out of the box. I imagine 4.2 wasn't fully finalized prior to hardware production, and they didn't want to hold it up until they were ready (wise choise!). In my case, within an hour after opening my N73G and turning it on, I had the 40C update notification. I applied this prior to rooting/modding/etc. ONLY after you are on 40C can you get the upgrade to 40D (4.2.1). Google pushes out incremental patch updates, so you can't skip a version.
So you have two options:
1) Apply update #1 and wait for #2 and then root/etc.
2) If you don't want to wait, and your device is still basically brand new and not setup (too much), AND assuming you want to root, customize, etc., just download the 4.2.1 system image from Google and fastboot flash it. You'll need to unlock the bootloader anyway, which will wipe your system, so now's a perfectly good time to do everything at once. Unlock bootloader, flash 4.2.1 stock (40D FULL IMAGE), flash custom recovery, install su zip, install any other mods (which is limited really to basic stuff and a custom kernel right now), enjoy.
Andoid 4.2.1 update
adamhlj said:
Is your device rooted? Is this your first android device? You will get a little notification in the notification bar at the top saying your deivce has an update.. If you have not rooted, you will receive the first OTA in a day or two that will go from JVP15S to JOP40C. Then later, you will receive the update for JOP40D. Some people have had success at forcing the update by going to settings, apps, all, google framework services, and selecting force stop then clearing the data. You then go back into settings, about device, check for updates and check for update.
Click to expand...
Click to collapse
Thanks!
It is my first Android device.
I am trying to root it (unsuccessfully).
I was able to get the FASTBOOT unlock - but cannot root because of the drivers interface...
I did update the firmware by forcing via framework system. Had to do in two steps as it only upgrades one generation at a time.
By the way - I had the "takju" - now it is "tilapia" after "official OTA update.
I hope to get the rooting problem resolved - all instructions on the net are for older ROMs and I already screwed up my work laptop installing obsolete PDANET drivers which replaced the original drivers - so my device manager which originally saw my Nexus 7 as "Nexus 7" now sees it as "Android Phone Device". I do not know how to recvert back.
So now I am going to try my other laptop for rooting.
Hopefully I could find just a "professional step by step procedure - unlike many that I found on the net. Many people just happy to get on YouTube to show themselves off but the advice is half ass.
Thanks again for your help though I am half way through.
Best regards
Vlad7777 said:
Thanks!
It is my first Android device.
I am trying to root it (unsuccessfully).
I was able to get the FASTBOOT unlock - but cannot root because of the drivers interface...
I did update the firmware by forcing via framework system. Had to do in two steps as it only upgrades one generation at a time.
By the way - I had the "takju" - now it is "tilapia" after "official OTA update.
I hope to get the rooting problem resolved - all instructions on the net are for older ROMs and I already screwed up my work laptop installing obsolete PDANET drivers which replaced the original drivers - so my device manager which originally saw my Nexus 7 as "Nexus 7" now sees it as "Android Phone Device". I do not know how to recvert back.
So now I am going to try my other laptop for rooting.
Hopefully I could find just a "professional step by step procedure - unlike many that I found on the net. Many people just happy to get on YouTube to show themselves off but the advice is half ass.
Thanks again for your help though I am half way through.
Best regards
Click to expand...
Click to collapse
I think you are either looking at really bad guides or simply making the rooting process much harder on yourself.
While some Android devices have more complicated unlocking/rooting/etc. requirements, that is not the case with Nexus devices - certainly not the Nexus7. The process couldn't be more simple. If you've already unlocked the bootloader, you are 1/3 of the way there. All you need to do is copy over a compatible "su" app zip to the device, install or run a custom recovery, install the su zip and voila - rooted.
If you already have fastboot running, that's the only tool you need. Download a custom recovery (CWM or TWRP) from a thread in this forum that is compatible, reboot into bootloader mode and install it:
fastboot flash recovery <recovery.img>
Then reboot into recovery mode (you can do this from bootloader), and you should be in CWM/TWRP. Then you simply install the SU zip using the menu on the screen.
It's a very simple process and does not require a special toolkit or anything like that.
phonic said:
I think you are either looking at really bad guides or simply making the rooting process much harder on yourself.
While some Android devices have more complicated unlocking/rooting/etc. requirements, that is not the case with Nexus devices - certainly not the Nexus7. The process couldn't be more simple. If you've already unlocked the bootloader, you are 1/3 of the way there. All you need to do is copy over a compatible "su" app zip to the device, install or run a custom recovery, install the su zip and voila - rooted.
If you already have fastboot running, that's the only tool you need. Download a custom recovery (CWM or TWRP) from a thread in this forum that is compatible, reboot into bootloader mode and install it:
fastboot flash recovery <recovery.img>
Then reboot into recovery mode (you can do this from bootloader), and you should be in CWM/TWRP. Then you simply install the SU zip using the menu on the screen.
It's a very simple process and does not require a special toolkit or anything like that.
Click to expand...
Click to collapse
Thank you for your reply and advice.
How do I place the "su zip" in the device and into which directory - I can try download directly to Nexus but needs to know where to place it.
Also what are "CWM" or "TWRP" And where do I place them for custom recovery procedure.
I apologize for my ignorance but Android is a complete new experience for me.
Vlad7777 said:
Thank you for your reply and advice.
How do I place the "su zip" in the device and into which directory - I can try download directly to Nexus but needs to know where to place it.
Also what are "CWM" or "TWRP" And where do I place them for custom recovery procedure.
I apologize for my ignorance but Android is a complete new experience for me.
Click to expand...
Click to collapse
You can place the "su zip" anywhere you like on the internal storage. When you get into custom recovery (CWM or TWRP), you can select "Install ZIP" (or something along those lines) and it will bring up a file system explorer that will let you select the one you want to install.
CWM and TWRP are both custom recoveries. They replace the stock, and very useless, recovery and give you many more advanced features. Things like flashing zip files, making nandroid backups, etc. You need to flash them to your "recovery" partition. It's a very easy process, but will require some specialized software. There are many guides and toolkits (if that's what you want to use) online. Just make sure you use the Talipia recovery (which exists now in the 3G forum).

Fixing failed OTAs after execution of TWRP

When booting TWRP using fastboot, without flashing it to the recovery partition, eg. "fastboot boot twrp-sanders-r20.img", only for the purpose of taking a partition backup, once done the device wont longer take OTA's!
That is IMHO a very unexpected behavior, as booting this way and keeping system read only should mean that nothing on the phone gets changed (well except the data partition if a backup is saved on these one).
One would expect this not to mess with the OTA process.
Now, this twrp at least: https://forum.xda-developers.com/moto-g5s-plus/development/recovery-twrp-3-1-1-r7-t3694910 does, after some investigation i found out that it is mounting the oem partition writable and modifying it adding a .twrp file to the root. Since the OTAs are checking and patching this partition of cause they will fail.
Luckily there is a way out, you can reflash the OEM partition for example from here: https://forum.xda-developers.com/moto-g5s-plus/how-to/tutorial-fhash-oreo-8-1-stock-global-t3852967
that is assuming that you are running the first Oreo 8.1 update, if you had an other version when the issue hit, you will need to find the right OEM partition image for you actual build.
IMHO this behavior of TWRP is unacceptable and should be fixed in a new release ASAP.
DavidXanatos said:
When booting TWRP using fastboot, without flashing it to the recovery partition, eg. "fastboot boot twrp-sanders-r20.img", only for the purpose of taking a partition backup, once done the device wont longer take OTA's!
That is IMHO a very unexpected behavior, as booting this way and keeping system read only should mean that nothing on the phone gets changed (well except the data partition if a backup is saved on these one).
One would expect this not to mess with the OTA process.
Now, this twrp at least: https://forum.xda-developers.com/moto-g5s-plus/development/recovery-twrp-3-1-1-r7-t3694910 does, after some investigation i found out that it is mounting the oem partition writable and modifying it adding a .twrp file to the root. Since the OTAs are checking and patching this partition of cause they will fail.
Luckily there is a way out, you can reflash the OEM partition for example from here: https://forum.xda-developers.com/moto-g5s-plus/how-to/tutorial-fhash-oreo-8-1-stock-global-t3852967
that is assuming that you are running the first Oreo 8.1 update, if you had an other version when the issue hit, you will need to find the right OEM partition image for you actual build.
IMHO this behavior of TWRP is unacceptable and should be fixed in a new release ASAP.
Click to expand...
Click to collapse
Agreed; received today a security update for my moto G5S plus (didn't root till i got the official 8.1 Oreo update) and every time i try to install takes me to TWRP and i keep it as READ ONLY (since TWRP itself says if u modify u won't b able to receive OTA updates) and... even without the modification i still can't get the update. this has to be fixed ASAP by TWRP
I did discover that if you keep the OTA files for older updates, you can re-run them to update the OEM partition. Unfortunately it only works one update generation.
I wonder if we just delete the .TWRP file if it can recover it. I'll test later this week. The OTA has a way to repair partitions
pizzaboy192 said:
I did discover that if you keep the OTA files for older updates, you can re-run them to update the OEM partition. Unfortunately it only works one update generation.
I wonder if we just delete the .TWRP file if it can recover it. I'll test later this week. The OTA has a way to repair partitions
Click to expand...
Click to collapse
keep us posted man
pizzaboy192 said:
I wonder if we just delete the .TWRP file if it can recover it. I'll test later this week. The OTA has a way to repair partitions
Click to expand...
Click to collapse
imho 99% sure, it still will fail, the partition does not just have to be semantically unchanged it must be 1:1 bit wise identical with what is expected.
I'll see what happens. I'm not a developer but I have pointed this out a few times to the developers of both TWRP threads, along with sharing these issues on the telegram group, but everyone else is focused on the latest custom ROM and doesn't care about stock, so the issues have fallen on deaf ears
in a nutshell how can i receive the last OTA security? do i revert to stock , install then root again? holy moly that's a lot of work
TheKicKer69 said:
in a nutshell how can i receive the last OTA security? do i revert to stock , install then root again? holy moly that's a lot of work
Click to expand...
Click to collapse
Unfortunately until they fix TWRP so it doesn't damage the OEM partition, you need a clean copy of the OEM partition to take the OTA.
However, there is a way you can prevent this, but it is a little hairy (you can't use any magisk modules). You can use the magisk app to patch the boot.img file that is from a slightly older Oreo firmware and flash that with fastboot, without using TWRP.
---------- Post added at 07:35 AM ---------- Previous post was at 07:30 AM ----------
DavidXanatos said:
imho 99% sure, it still will fail, the partition does not just have to be semantically unchanged it must be 1:1 bit wise identical with what is expected.
Click to expand...
Click to collapse
Yup. Just confirmed that deleting the .twrp file does not fix it.
I've reached out to Motorola to update their Lenovo Motorola Smart Assistant tool to support the official Oreo OTA which will allow us to download the latest full firmware file, which would give us the OEM partition to reflash before the next OTA.
I'll bother the TWRP devs again this week to get this unexpected behavior removed so we don't need to bother anyone in the future.
Update: none of the TWRP maintainers currently have replied to me about this issue.
@CheckYourScreen hasn't been active for a while but hasn't responded to a few different attempts to point this issue out (Been over a month since first notification with no acknowledgement)
@MasterAwesome has a custom TWRP that is latest, but they're still working on it. They're our best bet to possibly get it fixed since they're actively working on it. They've also been made aware, but no response yet (4 days since notifying and it was a weekend, so hopeful)
@GeneticEnginer was notified today. They developed the first unofficial TWRP (3.1.1) and might be able to help, but not holding my breath
I've also contacted a few people who do unofficial TWRP ports for some tips on unpacking one of our existing TWRP files and fixing it myself. It may be the way to go.
Hi guys. Final update. I've fixed TWRP temporarily. If we're not going to run custom ROMs, use this TWRP to backup. It does a bitwise backup of OEM and doesn't mount it as RW so it WILL work for restoring fully OTA capable stock ROM. It is NOT treble compatible as the treble compatible ones do weird things that I haven't documented.
https://forum.xda-developers.com/mo...-r20-stock-t3869192/post78205758#post78205758

May 2020 QQ2A.200501.001.B2 "FLAME" Magisk-Patched Boot Img [+UPDATE/KEEP ROOT GUIDE]

May 2020 QQ2A.200501.001.B2 "FLAME" Magisk-Patched Boot Img [+UPDATE/KEEP ROOT GUIDE]
Another month, another update. I'll keep churning out these patched / stock file uploads and easy noob-friendly update guides while guinea pigging the updates, so long as my area is still on lockdown and I'm not back to work yet, lol.
I've also installed and tested / verified that Kirisakura 4.2.0 is working great with this month's patch so far.
Also have EdXposed Canary 0.5.0.0 (4548) YAHFA installed. SafetyNet still passing as of now.
Magisk v20.4 Patched Boot Image: https://www.androidfilehost.com/?fid=4349826312261796525
Factory Untouched Boot Image: https://www.androidfilehost.com/?fid=4349826312261796524
THESE FILES ARE FOR 10.0.0 (QQ2A.200501.001.B2, May 2020, All carriers except TW) ONLY! PLEASE ONLY FLASH IF YOU KNOW WHAT YOU'RE DOING!
If these files and/or guides are helpful, please drop a thanks and let me know. =)
EASY UPDATE / SEAMLESS KEEP-ROOT UPDATE PROCESS (using a PC - a very intuitive, effective, and relatively safe method).
** You can only follow this guide exactly if coming from build QQ2A.200405.005, Apr 2020. But the general idea is the same for other builds, you just need the correct files for your device.
flame-qq2a.200405.005-factory-dtbo.img: https://www.androidfilehost.com/?fid=4349826312261796522
flame-qq2a.200405.005-factory-boot.img: https://www.androidfilehost.com/?fid=4349826312261763724
May 2020 sideload OTA zip: https://dl.google.com/dl/android/aosp/flame-ota-qq2a.200501.001.b2-46940f66.zip
I DID NOT BOOT BACK INTO O/S UNTIL ALL STEPS WERE COMPLETED - I DID THIS TO ENSURE EVERYTHING WOULD BOOT 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 flame-qq2a.200405.005-factory-boot.img
3. fastboot flash dtbo flame-qq2a.200405.005-factory-dtbo.img
......* these steps to restore stock recovery; dtbo.img also necessary for some kernel installations
-----------------
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 flame-ota-qq2a.200501.001.b2-46940f66.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 flame-qq2a.200501.001.b2-magisk_patched-20.4.img
9. done, start the phone
(Optional - Flash custom kernel. If you had a custom kernel, you need to re-flash it. I've only personally tested with Kirisakura though.)
This was a 100% seamless update that required no additional / re-setup of any of my Magisk or EdXposed 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.
Thank you for making this so convenient!
ahalol said:
Thank you for making this so convenient!
Click to expand...
Click to collapse
:highfive:
You can thank my wife for going with the P4 instead of P4XL . Now gives me 2 phones to keep up with, although they're basically identical in process. Might as well share with yall over on this board, which seems to get a little less love and attention. But we're definitely lovin the switch to Pixels. Awesome camera too, which is great because we just had our first child 4 months ago and these phones take amazing photos. And this is coming from 2 phones that already had great cameras (HTC U11 and U12+)! I love taking photos when he's sleeping using Night Sight mode. He's so adorable, it comes out so clean, and there's just something about that sleepy ambience .
i just saw on my google news feed that the May patch just started dropping to our devices. i go check XDA and this post is already here. wow that was fast haha! went perfectly smoothly just like last month, thanks so much!!
Why not update the OTA via Magisk, or is this only for those which devices is not able to download OTA:s?
Currently, I have rooted with Magisk, still waiting for OTA update notification in my device...
Should i restore images in Magisk and/or disable any modules or just let 'er rip?!
Vantskruv said:
Why not update the OTA via Magisk, or is this only for those which devices is not able to download OTA:s?
Currently, I have rooted with Magisk, still waiting for OTA update notification in my device...
Click to expand...
Click to collapse
redeyss said:
Should i restore images in Magisk and/or disable any modules or just let 'er rip?!
Click to expand...
Click to collapse
@Vantskruv: FYI, you won't get the OTA update notification because you're modified right now. You can restore the boot image in Magisk first and wait for the OTA notification (what you're thinking of is something like this: https://forum.xda-developers.com/pixel-4-xl/how-to/guide-update-retain-root-t4003839). But from what I understand, it's pretty hit or miss. Apparently it's hit or miss even on complete bone stock anyway lol. The method I outlined just works nice and reliably even when rooted and modded.
@redeyss: Restoring the stock boot image in Magisk Manager is similar to the method linked above, and then taking the OTA the normal way. But if you flashed a custom kernel, keep it mind it won't restore the dtbo partition (not sure if it's necessary with that method tbh). You shouldn't need to restore images in Magisk, nor diable any modules. When you flash the factory April boot and dtbo images, it's doing the same thing as restoring the images through Magisk (plus dtbo). Just let er rip, and if you have any issues, you can always flash the new unmodified factory boot image, which will essentially disable Magisk, and then work from there. It's a very safe method. =)
edit: also in the event of bootloop, this is a great thread to read and understand: https://forum.xda-developers.com/pixel-4/how-to/magisk-modules-disabler-booting-magisk-t3991739
Thank you @i5lee8bit for your answer. Luckily I have restrained myself yesterday to update, thought I where in the Pixel 4XL thread, while this is for the Pixel 4. :laugh:
I am just curious, do any of you expert guys/girls know why this is happening, that OTA updates is not pushed on rooted phones?
Do Google have algorithms that temporarily bans systems which is rooted?
Or is it so simple that some type of fingerprint is changed when rooted, so Google update services does not recognise the device, and not pushing OTA:s?
Sorry for the questions, no need to answer them. It was a long time ago I rooted Android:s, and I have forgot many things.
I think I will try to manually update everything, even though there are more steps included, just to learn how to do it.
https://www.youtube.com/watch?v=kZY8qiz2SZ0
Vantskruv said:
Thank you @i5lee8bit for your answer. Luckily I have restrained myself yesterday to update, thought I where in the Pixel 4XL thread, while this is for the Pixel 4. :laugh:
I am just curious, do any of you expert guys/girls know why this is happening, that OTA updates is not pushed on rooted phones?
Do Google have algorithms that temporarily bans systems which is rooted?
Or is it so simple that some type of fingerprint is changed when rooted, so Google update services does not recognise the device, and not pushing OTA:s?
Sorry for the questions, no need to answer them. It was a long time ago I rooted Android:s, and I have forgot many things.
I think I will try to manually update everything, even though there are more steps included, just to learn how to do it.
https://www.youtube.com/watch?v=kZY8qiz2SZ0
Click to expand...
Click to collapse
No worries, the process for the 4XL is the exact same, but good catch; you definitely need to use the correct files for the device. I actually posted a similar thread with the relevant 4XL files over on that forum.
Not sure exactly the mechanism used to prevent the normal OTA, but probably just checks for a modified boot partition. In any case, the normal factory OTA if I understand correctly relies in part on factory recovery commands at some point, and a modified boot partition won't be able to use them. In fact, try booting to recovery with the modified boot partition flashed and you'll notice it can't load recovery. I may be wrong about the exact reason though. But think about it: even if we had TWRP, the factory OTA mechanism can't make use of it. Even if the OTA popped up while rooted, it probably wouldn't be able to do it, or worse, cause a failure and corruption. I would dare say we're fortunate they prevent factory OTA when running modified.
Anyway, there are a lot of complicated guides out there, and that's why I wanted to share my method. I didn't need to do any further research and it's very intuitively sound. Steps 2+3 essentially restore stock boot and therefore recovery (and dtbo), the rest pretty much follows a standard OTA sideload, and then it's structured in such a way that you're flashing the new Magisk patched boot image before even starting the phone back up. Making it a seamless, keep-root easy upgrade.
Wow ..... what an easy, elegant way to get my Coral device updated while keeping root. Followed the OP process, but used these commands instead to get the June 2020 security update:
- fastboot flash boot coral-qq3a.200605.001-factory-boot.img
- fastboot flash dtbo coral-qq3a.200605.001-factory-dtbo.img
- adb sideload coral-ota-qq3a.200605.001-3b5bb1bd.zip
- fastboot flash boot coral-qq3a.200605.001-magisk_patched-20.4.img
Thanks, @i5lee8bit . Well done. :good:
does anyone have a thread to point me to that is a step by step guide for setting up ADB and how to flash? I did everything a year ago but now I just factory reset and am stuck in boot loop, can't remember all the commands and everything.
in_dmand said:
does anyone have a thread to point me to that is a step by step guide for setting up ADB and how to flash? I did everything a year ago but now I just factory reset and am stuck in boot loop, can't remember all the commands and everything.
Click to expand...
Click to collapse
Did you fix the issue?

Question PIXEL 5a Stable Build Available

If you haven't already, you should be receiving a notification that the Stable Android 12 or "S" Build is lurking in the shadows of your Pixel 5a handset. If you're currently on the (only) beta version we received OTA, your update won't inconvenience you for too long, as it weighs in at <4 mb, all in.
Safe Journey's...evnStevn
The factory images are up on Google's developer site, and when I tickled the system update found the 12 upgrade. I'm downloading the factory image now (for rooting with Magisk) then will upgrade to 12. Then more to learn...
CarinaPDX said:
The factory images are up on Google's developer site, and when I tickled the system update found the 12 upgrade. I'm downloading the factory image now (for rooting with Magisk) then will upgrade to 12. Then more to learn...
Click to expand...
Click to collapse
Right-On, I'm not ready for that, the Big League's (yet) as I'm still down here playing T-ball !
CarinaPDX said:
The factory images are up on Google's developer site, and when I tickled the system update found the 12 upgrade. I'm downloading the factory image now (for rooting with Magisk) then will upgrade to 12. Then more to learn...
Click to expand...
Click to collapse
Attempted the upgrade last night, seems there's some new things required if you want to flash the modified boot image and successfully boot. I believe you need to wipe the data partition and also pass along a few flags during install. However, temp root is an option if you want to avoid that for now (I did) by simply booting the image in fastboot vs flashing it. Just FYI!
Edit. Sounds like SafetyNet won't pass yet if you do end up going the permanent route? I could be wrong but I believe that's what's I've read. I just checked on mine and the temporary boot image does seem to so that's good.
If you read this thread you will see how to do it, as done on beta releases. https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/ It is possible to achieve permanent root on 12 without wiping the personal data but it is a delicate dance. I have not tried it yet but as I understand it the process is to unroot 11 and at least remove Magisk modules, take the 12 update, boot into bootloader and use fastboot to remove boot verification and replace vbmeta.img, then flash patched boot.img, reboot and reinstall magisk. It seems there is a problem with just flashing the new factory image with the wipe option (-w) removed. Instead of fastboot flashing the patched boot.img it is also possible to directly patch the boot.img from Magisk while temporarily booted from the patched boot.img (via fastboot), again after removing the verification checks. It may be critical as to when the 5a is rebooted or not; it needs to have a normal reboot after the OTA upgrade in order to complete the upgrade, then boot to bootloader for fastboot operations. I am going to go back and make instructions for myself before proceeding, and will do a Titanium backup before doing anything else.
Edit: it appears that some have achieved permanent root and still passed the SafetyNet check. IIRC it was done through the OTA upgrade path but I need to check that. If you are willing to wipe your data then just installing the factory image and then doing the fastboot commands it might work but that is not clear. Too many attempts at root and SafetyNet failed while flailing so hard to know right now if there are good alternatives to OTA.
CarinaPDX said:
If you read this thread you will see how to do it, as done on beta releases. https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/ It is possible to achieve permanent root on 12 without wiping the personal data but it is a delicate dance. I have not tried it yet but as I understand it the process is to unroot 11 and at least remove Magisk modules, take the 12 update, boot into bootloader and use fastboot to remove boot verification and replace vbmeta.img, then flash patched boot.img, reboot and reinstall magisk. It seems there is a problem with just flashing the new factory image with the wipe option (-w) removed. Instead of fastboot flashing the patched boot.img it is also possible to directly patch the boot.img from Magisk while temporarily booted from the patched boot.img (via fastboot), again after removing the verification checks. It may be critical as to when the 5a is rebooted or not; it needs to have a normal reboot after the OTA upgrade in order to complete the upgrade, then boot to bootloader for fastboot operations. I am going to go back and make instructions for myself before proceeding, and will do a Titanium backup before doing anything else.
Edit: it appears that some have achieved permanent root and still passed the SafetyNet check. IIRC it was done through the OTA upgrade path but I need to check that. If you are willing to wipe your data then just installing the factory image and then doing the fastboot commands it might work but that is not clear. Too many attempts at root and SafetyNet failed while flailing so hard to know right now if there are good alternatives to OTA.
Click to expand...
Click to collapse
Thanks for the link. I downloaded the full Android 12 image, installed it, disabled verity and wiped my data via fastboot, then flashed the magisk-patched boot. Worked like a charm and safetynet passed after hiding Magisk and installing Riru and the universal-safetynet-fix.
michaelc5047 said:
Thanks for the link. I downloaded the full Android 12 image, installed it, disabled verity and wiped my data via fastboot, then flashed the magisk-patched boot. Worked like a charm and safetynet passed after hiding Magisk and installing Riru and the universal-safetynet-fix.
Click to expand...
Click to collapse
I am hoping to avoid wiping data by taking the OTA and then rooting - I just need to find the time to backup and write down the process first. I knew that the update could be done directly with the factory image, then rooted, but that requires the data wipe. If I encounter a problem that is the fallback approach - then restore data with Titanium.
I don't mind wiping data once. But if I have to wipe data for each update just to root, I'll stay on 11 for now until there's a better way to root
Exactly.... I'll wait for a better way to upgrade and keep my root on 12
You don't "keep your root" on 11 updates; you unroot, take the OTA, then root again with a newly patched boot.img. And the data isn't wiped when moving to 12 if done through the OTA, just like 11 updates. If flashing a factory image the data is always wiped. What is different with 12 is that there is a verification of the boot.img and this has to be turned off (because the boot.img is patched), with a single fastboot command. It does appear to be sensitive to some details, so best to have a detailed procedure written down before starting the process. But those that have done it do not report a long or difficult process - just a finicky one.
CarinaPDX said:
You don't "keep your root" on 11 updates; you unroot, take the OTA, then root again with a newly patched boot.img. And the data isn't wiped when moving to 12 if done through the OTA, just like 11 updates. If flashing a factory image the data is always wiped. What is different with 12 is that there is a verification of the boot.img and this has to be turned off (because the boot.img is patched), with a single fastboot command. It does appear to be sensitive to some details, so best to have a detailed procedure written down before starting the process. But those that have done it do not report a long or difficult process - just a finicky one.
Click to expand...
Click to collapse
Ok ...have you done it yet?....can you tell me your process or elaborate more to my understanding
CarinaPDX said:
You don't "keep your root" on 11 updates; you unroot, take the OTA, then root again with a newly patched boot.img. And the data isn't wiped when moving to 12 if done through the OTA, just like 11 updates. If flashing a factory image the data is always wiped. What is different with 12 is that there is a verification of the boot.img and this has to be turned off (because the boot.img is patched), with a single fastboot command. It does appear to be sensitive to some details, so best to have a detailed procedure written down before starting the process. But those that have done it do not report a long or difficult process - just a finicky one.
Click to expand...
Click to collapse
I want to upgrade ota....but what do i have to do to achieve root without loosing files, setup, etc
No, I have not done it yet - oddly enough I have other things needing doing. The information needed to do it is in this thread: https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/ Unfortunately since it started during the 12 beta program, and there was a lot of trial and error, it is necessary to work through the long thread and sort out the process - which appears to be fairly simple (if inflexible).
When updating or upgrading there are always two paths to take: 1) take the OTA that is offered (after unrooting), or 2) flashing the full factory image. Generally speaking, OTAs are designed to keep the user data untouched [edit: not untouched but just converted where needed for the new system] and the factory image is intended to put the phone to factory condition (i.e. no user data present - starts from scratch). Updates (i.e. not upgrades between Android major versions) over-the-air (OTA) are replacing blocks of the stored image, which is very efficient, but requires a pristine stored image (hence the need to unroot to pass the check). Upgrades (new Android versions) seem to download the entire image, IIUC, and then clean up any data (like config files) that are not compatible with the new system. Sometimes the result has been less than perfect, although it is mostly reliable. Ultimately a factory image is the guarantee of getting a known good system, which can then be set up to the user's taste. Backing up user data (e.g. with Titanium Backup) and restoring can make this easier but again, config files from the previous system if restored on the new system can cause problems. Some people prefer to flash the factory image and reinstall the apps as new to get the highest confidence in the result. Most of us just take the OTA and trust the process, prepared to wipe config files or even flash the full factory image if there is a problem. Your choice.
After I write a procedure for myself, and successfully upgrade, I will post it.
So those of us that never rooted can just skip the unroot process and do the rest I assume?
CarinaPDX said:
No, I have not done it yet - oddly enough I have other things needing doing. The information needed to do it is in this thread: https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/ Unfortunately since it started during the 12 beta program, and there was a lot of trial and error, it is necessary to work through the long thread and sort out the process - which appears to be fairly simple (if inflexible).
When updating or upgrading there are always two paths to take: 1) take the OTA that is offered (after unrooting), or 2) flashing the full factory image. Generally speaking, OTAs are designed to keep the user data untouched [edit: not untouched but just converted where needed for the new system] and the factory image is intended to put the phone to factory condition (i.e. no user data present - starts from scratch). Updates (i.e. not upgrades between Android major versions) over-the-air (OTA) are replacing blocks of the stored image, which is very efficient, but requires a pristine stored image (hence the need to unroot to pass the check). Upgrades (new Android versions) seem to download the entire image, IIUC, and then clean up any data (like config files) that are not compatible with the new system. Sometimes the result has been less than perfect, although it is mostly reliable. Ultimately a factory image is the guarantee of getting a known good system, which can then be set up to the user's taste. Backing up user data (e.g. with Titanium Backup) and restoring can make this easier but again, config files from the previous system if restored on the new system can cause problems. Some people prefer to flash the factory image and reinstall the apps as new to get the highest confidence in the result. Most of us just take the OTA and trust the process, prepared to wipe config files or even flash the full factory image if there is a problem. Your choice.
After I write a procedure for myself, and successfully upgrade, I will post it.
Click to expand...
Click to collapse
Ok cool and thanks....that was awesome info
anubis2k3 said:
So those of us that never rooted can just skip the unroot process and do the rest I assume?
Click to expand...
Click to collapse
That is the case. It seems that some with 12 beta got tripped up by not getting unrooting/removing Magisk and/or its modules right so that is one less thing to worry about. If you have never rooted then the OTA should work as expected. Rooting can be done in two ways, either by achieving a temporary root and using magisk to directly patch the boot.img, or by patching the boot.img and flashing it, right after removing verification and flashing the new vbmeta.img (in both cases). Of course you first have to unlock the bootloader and enable USB debug, install the Android tools on your computer (minimum version: you only need ADB and fastboot), and connect your computer to the phone with a USB cable. Again, refer to that thread or wait until I can write something up.
CarinaPDX said:
That is the case. It seems that some with 12 beta got tripped up by not getting unrooting/removing Magisk and/or its modules right so that is one less thing to worry about. If you have never rooted then the OTA should work as expected. Rooting can be done in two ways, either by achieving a temporary root and using magisk to directly patch the boot.img, or by patching the boot.img and flashing it, right after removing verification and flashing the new vbmeta.img (in both cases). Of course you first have to unlock the bootloader and enable USB debug, install the Android tools on your computer (minimum version: you only need ADB and fastboot), and connect your computer to the phone with a USB cable. Again, refer to that thread or wait until I can write something up.
Click to expand...
Click to collapse
How do one remove verification?
I haven't been able to permanently root android 12 without wiping my data. I'm not talking about upgrading from 11 to 12. I'm talking about after installing 12, I still have my data. Any attempt to permanently root 12 causes errors unless I wipe my data. This was detailed quite a bit in the link you posted. Have you tried permanently rooting 12 and keeping your data?
As I said before, I have not had time to try the upgrade. Also, that thread has multiple conflicting posts which is why I know it will take time to go through and parse out what works and what doesn't. There are posts IIRC where root was achieved with data retained - but exactly how that was accomplished is not clear (or even if that really did happen). Since we have not had our phones for long there shouldn't be too much in data to lose, and there is always Titanium, so I will give it a go when I have time.
One of the things that I would like cleared up is if the way to 12 and root is to stop the OTA upgrade process at some point and remove verification and/or root before continuing, or possibly root fails because it is attempted before the upgrade is complete. IIRC the OTA has at least one reboot involved, with some processing after the reboot (probably fixing the data to be 12-compatible). Clearly if the upgrade can be done while retaining data and then successfully rooted then it must be done in a precise way; the lack of precise explanations of successful roots is very disappointing.
Edit: If it does turn out that data must be wiped every time 12 is rooted then that means backing up and restoring will be needed for each update, as well as unroot/root, and possibly removing verification each time. That would be a huge PITA. Let's hope that isn't so.
BlvckSensei816 said:
How do one remove verification?
Click to expand...
Click to collapse
It is explained in the thread I linked. But at this point unless you are willing to wade through 14 [make that 16 and counting...] pages of posts it is better to wait until someone posts a good procedure. Anyone not familiar with flashing is liable to get into trouble and needing a factory flash. However good 12 is, it is not so good that we can't wait a bit.

Question [NE2215] QUALCOMM crashdump mode

Hello everyone, i just tried updating to the latest ota on android 13 on a rooted 10 pro using the incremental magisk method and now my phone is bricked. wondering if there is a way to recover without losing data. Phone can boot into fastboot, anything else results in Qualcomm Crashdump mode being displayed on screen. ive connected to a computer and it registers when i type fastboot devices, from that point im pretty much stuck on next steps
I did the same mistake thinking it would work like it would on A12 and ended up sending it in to oneplus to reflash.
In my case I have a NE2215 converted to NE2213, what version are you? Full NE2215?
unsafe8989 said:
In my case I have a NE2215 converted to NE2213, what version are you? Full NE2215?
Click to expand...
Click to collapse
yes full ne2215. quite sad knowing we don't even have proper access to the tools to recover our own phones yet. luckily i kept my op8 for a situation like this.
ltw5ki said:
Hello everyone, i just tried updating to the latest ota on android 13 on a rooted 10 pro using the incremental magisk method and now my phone is bricked. wondering if there is a way to recover without losing data. Phone can boot into fastboot, anything else results in Qualcomm Crashdump mode being displayed on screen. ive connected to a computer and it registers when i type fastboot devices, from that point im pretty much stuck on next steps
Click to expand...
Click to collapse
you are sol. i already told you guys that you'll brick your phone if you use magisk method when updating os versions.
ltw5ki said:
Hello everyone, i just tried updating to the latest ota on android 13 on a rooted 10 pro using the incremental magisk method and now my phone is bricked. wondering if there is a way to recover without losing data. Phone can boot into fastboot, anything else results in Qualcomm Crashdump mode being displayed on screen. ive connected to a computer and it registers when i type fastboot devices, from that point im pretty much stuck on next steps
Click to expand...
Click to collapse
If you did unroot completely you can try to boot into EDL mode, in doing so I managed to flip the boot slot and get mine to boot when I was stuck in crashdump mode.
I updated to C.20 yesterday. The process is to unroot completely with image restore, reboot, then let the the update fully install and reboot. You will update fine but be unrooted. Then you boot a patched boot from bootloader and root directly from Magisk.
Do not forget the reboot after uninstalling Magisk before updating.
I already called op to start the repair process. I am willing to try the edl method in a last ditch effort. Is there a detailed explanation on how to get into edl and the process to flip the boot slot?
ltw5ki said:
I already called op to start the repair process. I am willing to try the edl method in a last ditch effort. Is there a detailed explanation on how to get into edl and the process to flip the boot slot?
Click to expand...
Click to collapse
I'm genuinely not sure how to flip the slot on purpose, it happened to me while I was trying the button combination for EDL mode. I believe you have hold all three buttons (Power, Vol Up&Down) until it restarts, it should vibrate but be a black screen and you can plug the USB in from there to see a port 9008 on the PC. This is very generalized but there are more details all around the forum here.
I will say I believe when it flipped, it booted and I saw the oneplus screen for a split second, the screen sort of glitched, and it immediately rebooted from black screen back to bootloader. I think the switch occurred then.
Also is that from a powered off state or is it possible to do with the phone being on?
Hmmm... I can get into bootloader okay and even launch recovery, but I can't seem to switch the partitions. I contacted support, they can replace the phone, but can't or won't tell me how to switch partitions or load it manually.
Quantumrabbit said:
Hmmm... I can get into bootloader okay and even launch recovery, but I can't seem to switch the partitions. I contacted support, they can replace the phone, but can't or won't tell me how to switch partitions or load it manually.
Click to expand...
Click to collapse
If you can get into bootloader, can you try to fastboot boot a boot image? Does that also lead to a qualcomm crashdump?
Prant said:
If you can get into bootloader, can you try to fastboot boot a boot image? Does that also lead to a qualcomm crashdump?
Click to expand...
Click to collapse
The problem is I don't know if I have any fastbootable images... I have the C19 full zip... would that work to try and fastboot it? Do I fastboot just the C19 bootloader?
I'm not used to being in the situation I'm in right now
Quantumrabbit said:
The problem is I don't know if I have any fastbootable images... I have the C19 full zip... would that work to try and fastboot it? Do I fastboot just the C19 bootloader?
I'm not used to being in the situation I'm in right now
Click to expand...
Click to collapse
Just take a step back and don't do anything rash. Absolutely do not FLASH anything in fastboot, but there are numerous guides around here. You basically want to extract the boot.img from that full upgrade zip's payload.bin file, easiest way being with FastbootEnhance, then use command 'fastboot boot "boot.img"' while you're on bootloader. I'm not sure if this will boot your phone, but it definitely can not damage it as long as you're just booting, so it's worth a shot.
Prant said:
Just take a step back and don't do anything rash. Absolutely do not FLASH anything in fastboot, but there are numerous guides around here. You basically want to extract the boot.img from that full upgrade zip's payload.bin file, easiest way being with FastbootEnhance, then use command 'fastboot boot "boot.img"' while you're on bootloader. I'm not sure if this will boot your phone, but it definitely can not damage it as long as you're just booting, so it's worth a shot.
Click to expand...
Click to collapse
Hey man I'd like to poke at your brain if you don't mind, so I did the same thing as quantumrabbit, didn't reboot after unrooting and got the same issue. My problem was my dumba** tried to follow one of the fastboot guides to try and recover my phone and boy let me tell you I bricked my phone harder then I've ever bricked a phone lol. Anyway I got into contact with OP shipped them the phone, they claim to have repaired it and it should get back to me tomorrow, overall took 2 weeks. I want to avoid doing in this future as root is a must for me, before the 10 Pro I had a 6T. Whenever I was on that device from OOS 9,10 & 11 and custom roms after the update support was over, I was always able to unroot without rebooting, flash the full OTA zip and then install magisk to the next inactive slot. It would work and I would retain root. When I got my 10 Pro, for the first 4 updates that came out for the NE2215 where only incremental. So my method was unroot with no reboot, install the incremental ota, then install root to inactive slot and it worked some how even being incremental updates and without the reboot. Well then, I then converted my NE2215 to a NE2213 using the rollback package, and then update normally until C19 released where I fully unrooted and even factory reset for the OS jump from A12 to A13. C20 came out, and this is where I tried the same stupid method, unroot with no reboot, install full OTA zip, then flash magisk to the inactive slot, this then immediately gave the Qualcomm error people are getting. My question is, is that reboot mandatory and should it always be done, since I never had a issue before hand it slipped my mind. I hope you understand what I'm trying to ask, basically I want to avoid this issue in the future especially with no MSM and OP taking their sweet time to fix my phone, should I always completely unroot and reboot for absolutely any OTA and just manually root again by booting the boot image I'm pretty sure that's a no brainer "yes" to my question but more or less I wanna know what changed from Android 12 where I was able to use the un-recommended method with 4 consecutively updates on NE2215 and about 2 of them on NE2213 after converting. I'd like your insight on why it should be done the correct way and what issues arise etc as you seem knowledgeable. Also the possibilities on how to recover, I saw your solution where you recommend booting a boot image to see if that would work, didn't even cross my mind but I think that would've been the correct approach instead of jumping straight into fastboot flashing like my dumb self did. Thank you!
unsafe8989 said:
Hey man I'd like to poke at your brain if you don't mind, so I did the same thing as quantumrabbit, didn't reboot after unrooting and got the same issue. My problem was my dumba** tried to follow one of the fastboot guides to try and recover my phone and boy let me tell you I bricked my phone harder then I've ever bricked a phone lol. Anyway I got into contact with OP shipped them the phone, they claim to have repaired it and it should get back to me tomorrow, overall took 2 weeks. I want to avoid doing in this future as root is a must for me, before the 10 Pro I had a 6T. Whenever I was on that device from OOS 9,10 & 11 and custom roms after the update support was over, I was always able to unroot without rebooting, flash the full OTA zip and then install magisk to the next inactive slot. It would work and I would retain root. When I got my 10 Pro, for the first 4 updates that came out for the NE2215 where only incremental. So my method was unroot with no reboot, install the incremental ota, then install root to inactive slot and it worked some how even being incremental updates and without the reboot. Well then, I then converted my NE2215 to a NE2213 using the rollback package, and then update normally until C19 released where I fully unrooted and even factory reset for the OS jump from A12 to A13. C20 came out, and this is where I tried the same stupid method, unroot with no reboot, install full OTA zip, then flash magisk to the inactive slot, this then immediately gave the Qualcomm error people are getting. My question is, is that reboot mandatory and should it always be done, since I never had a issue before hand it slipped my mind. I hope you understand what I'm trying to ask, basically I want to avoid this issue in the future especially with no MSM and OP taking their sweet time to fix my phone, should I always completely unroot and reboot for absolutely any OTA and just manually root again by booting the boot image I'm pretty sure that's a no brainer "yes" to my question but more or less I wanna know what changed from Android 12 where I was able to use the un-recommended method with 4 consecutively updates on NE2215 and about 2 of them on NE2213 after converting. I'd like your insight on why it should be done the correct way and what issues arise etc as you seem knowledgeable. Also the possibilities on how to recover, I saw your solution where you recommend booting a boot image to see if that would work, didn't even cross my mind but I think that would've been the correct approach instead of jumping straight into fastboot flashing like my dumb self did. Thank you!
Click to expand...
Click to collapse
your jumping around probably screwed up some partition size. I did not restart for the c20 ota and have no issues.
unsafe8989 said:
Hey man I'd like to poke at your brain if you don't mind, so I did the same thing as quantumrabbit, didn't reboot after unrooting and got the same issue. My problem was my dumba** tried to follow one of the fastboot guides to try and recover my phone and boy let me tell you I bricked my phone harder then I've ever bricked a phone lol. Anyway I got into contact with OP shipped them the phone, they claim to have repaired it and it should get back to me tomorrow, overall took 2 weeks. I want to avoid doing in this future as root is a must for me, before the 10 Pro I had a 6T. Whenever I was on that device from OOS 9,10 & 11 and custom roms after the update support was over, I was always able to unroot without rebooting, flash the full OTA zip and then install magisk to the next inactive slot. It would work and I would retain root. When I got my 10 Pro, for the first 4 updates that came out for the NE2215 where only incremental. So my method was unroot with no reboot, install the incremental ota, then install root to inactive slot and it worked some how even being incremental updates and without the reboot. Well then, I then converted my NE2215 to a NE2213 using the rollback package, and then update normally until C19 released where I fully unrooted and even factory reset for the OS jump from A12 to A13. C20 came out, and this is where I tried the same stupid method, unroot with no reboot, install full OTA zip, then flash magisk to the inactive slot, this then immediately gave the Qualcomm error people are getting. My question is, is that reboot mandatory and should it always be done, since I never had a issue before hand it slipped my mind. I hope you understand what I'm trying to ask, basically I want to avoid this issue in the future especially with no MSM and OP taking their sweet time to fix my phone, should I always completely unroot and reboot for absolutely any OTA and just manually root again by booting the boot image I'm pretty sure that's a no brainer "yes" to my question but more or less I wanna know what changed from Android 12 where I was able to use the un-recommended method with 4 consecutively updates on NE2215 and about 2 of them on NE2213 after converting. I'd like your insight on why it should be done the correct way and what issues arise etc as you seem knowledgeable. Also the possibilities on how to recover, I saw your solution where you recommend booting a boot image to see if that would work, didn't even cross my mind but I think that would've been the correct approach instead of jumping straight into fastboot flashing like my dumb self did. Thank you!
Click to expand...
Click to collapse
Yeah, flashing on this device is a big no go until we get proper recovery tools. 9 times out of 10 you'll make things worse.
While you have people like @g96818 that don't use the full reboot, PC method; when I tried to use that method for C.19, I was the one stuck in qualcomm crash dump last month. When I posted I was informed that with this device, especially since Android 13, doing the incremental systemflash then trying to install magisk to inactive *CAN* leave some weird errors in the system update process.
Either way, for me personally, after that big a scare. I will always update using the full uninstall Magisk with restore images, reboot, flash system update, let it do its thing, then root again using a magisk patched boot image, which is super simple to do. You can use cross region boots, as in 2213 on 2215, done that the past two times. Just remember to never flash, only boot.
Appreciate your guys input, I'll make sure to be extra cautious! Phone comes in today, fingers crossed I successfully update to C20 and root! Lol.
Prant said:
Yeah, flashing on this device is a big no go until we get proper recovery tools. 9 times out of 10 you'll make things worse.
While you have people like @g96818 that don't use the full reboot, PC method; when I tried to use that method for C.19, I was the one stuck in qualcomm crash dump last month. When I posted I was informed that with this device, especially since Android 13, doing the incremental systemflash then trying to install magisk to inactive *CAN* leave some weird errors in the system update process.
Either way, for me personally, after that big a scare. I will always update using the full uninstall Magisk with restore images, reboot, flash system update, let it do its thing, then root again using a magisk patched boot image, which is super simple to do. You can use cross region boots, as in 2213 on 2215, done that the past two times. Just remember to never flash, only boot.
Click to expand...
Click to collapse
One last question, do you remove all your modules first reboot then unroot and reboot?
Prant said:
Yeah, flashing on this device is a big no go until we get proper recovery tools. 9 times out of 10 you'll make things worse.
While you have people like @g96818 that don't use the full reboot, PC method; when I tried to use that method for C.19, I was the one stuck in qualcomm crash dump last month. When I posted I was informed that with this device, especially since Android 13, doing the incremental systemflash then trying to install magisk to inactive *CAN* leave some weird errors in the system update process.
Either way, for me personally, after that big a scare. I will always update using the full uninstall Magisk with restore images, reboot, flash system update, let it do its thing, then root again using a magisk patched boot image, which is super simple to do. You can use cross region boots, as in 2213 on 2215, done that the past two times. Just remember to never flash, only boot.
Click to expand...
Click to collapse
Technically that's on you. I gave a warning that you will brick if you don't fully unroot for c19.
Quantumrabbit said:
The problem is I don't know if I have any fastbootable images... I have the C19 full zip... would that work to try and fastboot it? Do I fastboot just the C19 bootloader?
I'm not used to being in the situation I'm in right now
Click to expand...
Click to collapse
I posted the c20 boots and how to flip the boot so go try it out.

Categories

Resources