About the time I recovered my semi-bricked OnePlus 8 Pro

Let me tell you about the time I spent a weekend - and even some extra nights - trying to bring back a phone that refused to cooperate.

I have a spare OnePlus 8 Pro that I keep around. Its support was long dropped by OnePlus, battery life wasn’t at its best point, and security patches were long gone. The solution? A custom ROM. I installed CrDroid and it worked great for a while.

Then one day, after a local update - because OTA wasn't working - the Play Store stopped functioning. Fine. I'd just boot into recovery, sideload updated GApps, and keep on with my life.

Except recovery didn't boot. And then I noticed normal Android wouldn't boot either. Nor fastboot. The only thing that worked was the bootloader.

The phone was semi-bricked.

Bootloader vs Fastboot: Not the Same Thing

This was my first real lesson from the whole ordeal, and it's one I didn't expect.

The bootloader and fastboot look identical on screen. Same menus, same interface. But they are not the same thing at all. The bootloader is a much more restricted environment - it enforces strict signature verification on everything and won't let you touch dynamic partitions. Fastboot (or fastbootd, the userspace version) is far more permissive and is what you actually need when doing custom ROM work.

The problem is that fastbootd runs from inside the boot image. So if your boot image is broken, you can't get into fastbootd.

I spent a good chunk of time throwing commands at the bootloader and wondering why they were either failing silently or throwing verification errors. Turns out I was trying to do fastbootd things from the bootloader. That doesn't work.

The MSMDownloadTool Adventure

When flashing images through the bootloader stopped being an option, I looked into going lower level. OnePlus has an unbrick tool called MSMDownloadTool that works through EDL - Qualcomm's Emergency Download mode. It completely bypasses Android and talks directly to the chip.

I found the package for my device's EU variant, entered EDL mode by holding both volume buttons while plugging the USB cable, and the tool detected the phone just fine.

Then it immediately failed with "param preload failed."

Every. Single. Time.

After some investigation, I learnt that the OOS11 package I had was designed for a completely different partition layout than what CrDroid was using. Android 16 and Android 11 organize their partitions very differently, and the tool just couldn't reconcile that.

A Crash Course in Android Partition Layouts

This is something I knew existed but had never really sat with until this situation forced me to.

Modern Android uses something called dynamic partitions. Instead of having fixed partitions for system, vendor, and product, they all live inside a single logical container called super. The actual sizes are managed at runtime.

The implication when you're trying to unbrick: you can't just flash a system.img directly. It needs to go inside super. And building a proper super image requires knowing exactly what partitions it contains and their sizes — which differ between Android versions and between ROMs. Of course this meant I had to extract the .img from the payload and tweak them into a bigger image.

This is why mixing images from different sources or different Android versions almost always ends in AVB verification failures. The bootloader checks cryptographic hashes and if anything doesn't match its expectations, it refuses to boot and shows you an error screen.

I saw a lot of error screens.

Going Nuclear with edl.py

At some point I discovered bkerler's edl.py - an open source tool that does what MSMDownloadTool does but gives you raw access to every partition without the proprietary overhead. I got it running on a Linux VM (the tool works much better on Linux than Windows due to USB driver timing issues) and was finally able to read the full partition table and flash/erase the partitions directly.

This was the point where I felt like I actually had control over the situation. I could read partitions, write them, erase them. I flashed everything I could find - OxygenOS 11 images from a community package, CrDroid images extracted from the zip's payload, vbmeta images with verification patched out.

The phone still showed the same "current image has been destroyed" error screen every time I tried to boot anything other than the bootloader.

The Unexpected Fix

After days of this, I was going back and forth between different approaches when something unexpected happened. I tried LineageOS images.

And it worked…

A fun fact is that, at this point, I was using Gemini -another Google product, I figured it might know Android better- to try anything it was worth trying. I hadn't mentioned LineageOS at any point. Gemini just... suggested it.

I can't tell you with full certainty which exact flash was the one that made the difference. There were so many attempts, so many error screens, so many reboots that by the time fastbootd started responding -not always but once is enough- I couldn't pinpoint the exact cause. From there I flashed the images, the LineageOS recovery loaded, I wiped data, and sideloaded a working ROM.

The phone finally booted.

What I Actually Learned

The bootloader is not fastboot. I cannot stress this enough. If you're trying to do custom ROM work and things aren't working, make sure you know which environment you're actually in.

Partition layouts change between Android versions. What works for Android 11 won't necessarily work for Android 16. If you're mixing images from different sources or different Android generations, expect problems.

EDL is a last resort that may actually work. If your Qualcomm phone can enter EDL mode, you have raw access to every partition on the device. It's not beginner-friendly but it's the lowest software level you can reach without a hardware programmer.

Sometimes the fix comes from an unexpected place. I spent days on OxygenOS and CrDroid images. LineageOS - which I wasn't even planning to install - is what got me back in.

In Hindsight

I already knew custom ROM updates could go wrong. But this was the first time I'd seen a seemingly successful update leave the device in a state where nothing would boot afterwards. It was also the first time I really had to sit with the differences between Android versions at the partition level - not just read about them but actually feel the consequences.

The OnePlus 8 Pro is running again. Battery still isn't great. But it's alive, and now I understand its internals better than I probably ever wanted to.

If you're in a similar situation: don't write off the phone until you've tried EDL. It can recover things that look completely dead.

Moving into a different ROM is also a possibility. LineageOS wasn’t even in mind but seeing its recovery was a great feel and the best sign I was on the right track.