When I first heard Android N Dev Preview was available as an OTA, I was ecstatic. No need to lose your user data like you would with a full factory image. No more dealing with ADB and FASTBOOT. I enrolled my Nexus 9 into the Android Beta Program (which is new for Google), and a minute later I got a System Update notification for the upgrade.

The process is the same as with any other updates, except it took a while to download since it was about 1 GB in size. Then it happened: ERROR! That's all it said underneath an Android logo that's lying on it's back with a red triangle with an exclamation point.

I also posted on a few Google+ groups, but I have no idea how to link those cleanly.

THE (SOFT) BRICK WALL

So the problem isn't just a failed OTA. The problem is when the OTA failed, it already written to the system partition so now the darn thing won't boot into the OS anymore. And because you can't boot into the OS, you can't enable Developer options to also enable OEM unlocking (which allows you to unlock the bootloader). What fascinates me is the Full Factory Images aren't signed, which means you must unlock the bootloader before you can even flash your device with a factory image. You are basically treating the factory image like a custom image.

So that’s the brick wall - a catch 22, if you will. You can't flash the factory image without booting into the OS and enabling OEM unlocking. This feature is new to Android/Nexus. This will prevent stolen devices to be reused again if someone just does a factory reset. It also prevents a thief from side-stepping this security measure by flashing a factory image or custom ROM. But it can also lock out legitimate owners if an OTA update fails. Basically you have a soft bricked device.

THE SOLUTION

Normally OTA updates check the system partition for a specific version of Android before being applied. This is done so you don't accidentally install the wrong patch for the wrong OS version since these OTA updates are usually deltas and not the full OS image. This keeps the size of OTA updates small.

The solution, of course, is for Google to make it public link to download the OTA for Android N Dev Preview. This file is a full-block OTA which is basically a complete OS image that replaces everything in the system partition, so no check is needed. And that's exactly what they did. Google provided links to download the signed OTA update files for people to side load into their devices without the requirement of unlocking their bootloaders.

Side loading OTAs isn't anything new. The Android community have extracted the links to download these OTAs from logs and provide them to the rest of the community since almost the begining. However, this is the first time Google publically provided a link to OTA files.

HOPEFULLY A LESSON LEARNED BY GOOGLE

I hope Google will continue to provide full-image OTAs for major version releases in the future to resolve instances like this. With the requirement of enabling OEM unlocking in the new Nexus devices, full-image OTAs like these would be required to recover from failed standard OTA updates. I imagine this can happen with the monthly OTA security updates. Who knew we were dodging bullets all those times?

For those concerned that stolen devices can be re-purposed this way, fear not. Even with a factory reset (no more user data), after flashing this OTA to get my Nexus 9 working again, it asked me to authenticate with the last owner's credentials before letting me in. So this should still deter thieves if they get a hold of a full-image-OTA thinking they can just flash a factory image with a locked bootloader. Much safer than leaving the bootloader unlocked or keeping OEM Unlocking enabled.

Another reason why it's a good idea compared to the old Full Factory Image method: OTAs do not delete user data.

I seriously hope the Google Android team consider releasing full-image OTAs in the future as standard practice - at least for major Android releases (no need to do this for all the minor updates - kind of like reinstalling Windows and getting all the security updates).

Creating a full-image OTA shouldn't add much to their workflow. The OTA for Lollipop to Marshmallow, for example, would have to be a full-image OTA anyways. The only thing the Android team needs to do is to disable version checking so it can be side loaded no matter what state the system partition is in.

Also, if a user wants to keep their data partition intact, a full-image OTA for the major release is important. If Google only released a single full-image OTA for the original OS the device released with (example: Lollipop), if someone needs to recover from a bad OTA update when they're already in Marshmallow, the original Lollipop build may not work with the new data partition schema.

Of course you'd be thinking "I'll just be happy the device is not bricked", but if you can also solve the "I'm glad I didn't lose any data" dilemma without much effort, why wouldn't you?