Being able to remotely wipe your phone's data is a handy feature and, in conjunction with Android's Device Protection, can make your phone all but useless to a would-be thief. I say "all but" useless because there's always the possibility of a workaround or a deep compromise of your account information that could let a thief into your device in an extreme scenario. Granted, almost nothing can claim to completely eliminate the risk of data theft once your accounts are compromised, but there are steps that can be taken to at least mitigate the damage, even if just long enough to get back control of your stuff.

As such, a mere wipe of user data may not be enough. But what if there was a way to remotely wipe and brick your phone (i.e., render it unbootable)? Perhaps with a big, red button. A feature which I shall now call The Nuclear Brick. That's what the new recovery-based brick function merged into AOSP seems to intend to provide Android device manufacturers. It appeared in AOSP on Friday, and it takes "wiping" to a whole new level. Namely, the level of bricking. When initiated, the brick command can securely erase (write to zeroes) any partition on your Android device, including the recovery, boot, and bootloader themselves (at which point, recovering the device without dedicated JTAG hardware is often impossible). Manufacturers would be able to define just which partitions are included in the brick command, with the ability to add things like a partition for an external SD card, for example. Most likely, implementations would make the device unbootable while still providing the user the ability to recover the device without any special hardware once they have it back.

There is currently no information in regard to when or if Google plans to implement this as a consumer-facing feature as part of the Android Device Manager, though its future presence seems all but assured for enterprise applications like Android for Work, to allow MDM tools to remotely and securely disable Android devices. Obviously, remote bricking is an extreme measure, and Google couldn't go around enabling it by default for ordinary consumers without having a foolproof software tool to recover their devices once it has been utilized, and that's a fair bit more work than just writing the command that's been added to AOSP. So, while it may not be a feature of Android N in any exposed sense, it could be something we'll be able to take advantage of as part of an ADM update down the road (or not, who knows).