[Miscellaneous Android Development] Dib Membrane:
***WARNING*** — Magisk 16.7 bricked my R2; haven't been able to recover it

So I let my R2 unit finish doing its 10-failed-auths factory reset, but when it rebooted, it just hung indefinitely on the initial white ZTE screen (doesn't boot-loop — just hangs). Tried rebooting a few more times; same thing. I tried using Volume Up to get into what I assumed would now be the factory recovery again, but it just hangs on the initial boot screen when doing that too. It can't be turned off either — if you hold down power, it automatically starts booting again right after the screen goes black, regardless of how fast you let go of the power button. And no device shows in the Device Manager, so of course ADB also cannot see the phone.

At this point I ejected the SIM + microSD tray, in case one of the ZIP files I had sitting at the root was causing it to try to do a boot-time install or something, but I get the same behavior with the tray out. I then decided I better copy my TWRP Nandroid backups with my SD card reader to my PC for safe-keeping, but was rather shocked to discover that the 10-wrong-auth-attempts factory reset had evidently also reformatted my SD card! :mad: This is despite the fact that I had the card formatted as portable storage, not adopted as virtual internal storage. In retrospect, I can see why they'd do this, since if you're wiping the device to prevent someone from brute-forcing their way into accessing your data, you probably wouldn't want them to have access to the data on your SD card either, but since the warning message didn't say anything about the factory reset messing with the SD card, this discovery really knocked the wind out of me. Luckily I didn't lose much valuable data (just a few things I'd put on the card since the last backup of my previous Android device, a now-dead Motorola).

After a lot of research, I came upon people talking about "deep flash cables", and found a YouTube tutorial where a guy showed how to make a poor man's version where you use a strand of copper wire to short pin 2 to the metal shell on the Type-A connector end of the USB cable. I actually couldn't manage to get the wire to stay in place properly (the guy in the video had to mess with it for a long time too), but luckily I had some self-adhesive circuit tape, which did the trick nicely. The only way I finally got my R2 to do something else besides hang on the initial boot screen was to short pin 2 on the USB cable that way, then plug it in to a USB 2.0 port (I came across lots of unexplained warnings saying USB 3.0 ports might or might not work), then hold down Power, Volume Up, and Volume Down, then let go of Power once the screen went black, then let go of Volume Up and Volume Down (it'd usually take one extra reboot before it'd stay black rather than trying to boot again). The R2 won't show up in the Device Manager at this point, but you then unplug the connector, remove the shorting tape/wire, then plug it back in (no need to pull it out while leaving the connector plugged in like the guy in the video claims; people also said to use a rear USB port on a desktop rather than a front port, but my front port worked fine).

At that point the R2 shows up in the Device Manager under "Ports (COM & LPT)" as "ZTE Handset Diagnostic Interface(DFU) (COM#)". ADB still can't see it at that point (and I tried several different copies of ADB during all this, including the one that comes with the Android SDK; the one that comes with the ZTE drivers; the extra copy that the installer for the latter apparently puts in C:\Windows\system32, which causes problems until you delete it; and the one that comes with XiaoMiFlash / MiFlash). XiaoMiFlash also fails to see the R2 in DFU mode. QFIL can see it, but after it tries to "Switch To EDL", it gets [sic]:

Download Fail:Switch To EDL FailFailed to Switch to Emergency Download mode

However, if I run the ZTE DFU_MultiDL_A2017X_Tool / ZTE_Sales_Update_Framework.exe, it switches the phone into what should be EDL mode, and the port in the Device Manager switches to "Qualcomm HS-USB QDLoader 9008 (COM#)". I can't do any flashing with the tool, as the port shows up in "DISCONNECT" state, and the "play" button thus doesn't do anything. It really does switch the phone to a different mode — it doesn't just change how Windows sees it — as if you unplug and replug, it shows back up in the Device Manager in 9008 mode. ADB still can't see it at this point (nor can fastboot, but I understand fastboot doesn't ever work with the R2).

I read a ton of unbricking threads and tried various different versions of tools, and just after I uninstalled the version of MiFlash linked from the lead post of the "[GUIDE][G,U,Ch] DFU Unbrick Guide - Disassembly" thread here, I got a rare BSOD on my nice stable Windows 7 system, and after my machine came back up, the phone still connected in 9008 mode, so it's definitely getting switched out of DFU — it's not just Windows changing drivers. Speaking of different versions of MiFlash, after the phone connects in 9008 mode, the version of MiFlash linked to in the "[ROM] ZTE Visible R2 Stock firmware" thread (and possibly this thread too; I forget) still can't see the R2. Out of all the versions of MiFlash I tried, the only one I found that can see it (after hitting "refresh") is the beta version from the "[Updated ]Xiaomi Flashing Tool Miflash(Beta Version) Released! Download It Here - Xiaomi Mi 5/Pro - Xiaomi MIUI Official Forum" thread on the MIUI site. Unfortunately after 5 seconds of waiting to "read hello packet", it gets the error:

can not read from port COM[i]#[/i]

QFIL can also see the device at this point (after running ZTE DFU_MultiDL_A2017X_Tool to switch it into what should be EDL mode), but after selecting "Flat Build", the prog_emmc_firehose_8917.mbn, and the two XML files, it hangs for a minute or two after printing the Working Folder, then says (leaving out the timestamps):

ERROR: function: sahara_rx_data:237 Unable to read packet header. Only read 0 bytes.
ERROR: function: sahara_main:924 Sahara protocol error
ERROR: function: main:303 Uploading Image using Sahara protocol failed
Download Fail:Sahara Fail:QSaharaServer Fail:Process fail

So it appears that somehow Magisk 16.7 hosed the firmware that's supposed to run in the EDL mode and speak Sahara protocol to the PC, either at install time, or it triggered this to happen at the time of the 10-wrong-swipe-codes factory reset. (TWRP could also be involved, but since it was working perfectly until the Magisk install, and recovery was unreachable after that, it seems unlikely to be at fault.)

I've done a ton of reading, tried a bunch of alternate tools, etc., but I can't find any way to unbrick my R2. :crying: On the page "[GUIDE/TOOL]the ultimate DFU UNBRICK TOOL - Pg. 11 | ZTE Axon 7", someone was reporting that their Axon was in the same condition as my R2, and another poster said they could recover it by letting the battery drain completely and then trying again to go into EDL mode. I let my R2 battery drain on the initial boot screen overnight, then pressed power and got a screen with a battery graphic and "Battery empty, plug in charger for a few minutes, then power on." I did so, then plugged the USB cable into my PC without the pin 2 short, and held Power, Volume Up, and Volume Down, but it came up and hung on the white ZTE screen again. On the second try, it went into DFU mode, and behaved the same as described above from that point on. So the only thing the battery draining seems to have accomplished is that I can now get the phone into DFU mode without having to do the pin 2 shorting thing. Interesting, but only marginally helpful.

[MENTION=3540215]FEGuy[/MENTION], do you or anyone else know any way to unbrick my R2? Or is it permabricked without sending it in to ZTE for warranty replacement? Is it likely that they'll send me a free refurb even though I was flashing stuff onto the device? The only thing I came across that I didn't try is the unbrick method where you have to disassemble the phone and then short the test point / test pad, but though I've disassembled and reassembled other phones successfully before, the R2 doesn't look like one I could do without leaving any traces, especially without a guide.

And then when I get a replacement R2, any thoughts on avoiding this happening again? I really want root, as I have a lot of apps that depend on it, including Titanium Backup, and multiple Android apps that sync data with an equivalent Windows application by connecting in USB Mass Storage mode. I also use a Perl script I wrote to sync my music over to my Android which depends on USB Mass Storage mode and having a drive letter assigned. And aside from MTP mode lacking drive letter assignment, I've found it to be extremely flaky on large copies/moves.

I could simply try going the route of the replacement boot.img and Magisk 19.3, but now I'm pretty gun-shy about potentially permabricking my replacement R2 too. Any advice or help would be much appreciated!