I have solid experience with installing different OSes (Linux, Windows,...) on PCs. I would like to try just for fun to install Linux on an unbranded Android low cost tablet acquired in 2015. I spent some time browsing the web and as far as I understand there is a risk that during the flash procedure the device could be potentially damaged. So I read extensively on how to backup the ROM using TWRP and all related matters. I would like just to have some explanations on the below topic:

Scenario #1:
I have a PC, if I want to try another OS I can just format the hard disk and install it, in no way is there a risk of damaging the BIOS or motherboard. Motherboard and hard-disk are separated, so no problems can arise.

Scenario #2:
I have a tablet, want to wipe out Android and install an upgraded version of Android or a Linux distro suitable for mobile devices.

  • Why in this scenario is there a risk of ending up with an unusable device?
  • Is this because in this case the motherboard and unit memory are bundled together? So wiping the memory would also erase the configuration settings of the motherboard?
  • Do we have here the equivalent of BIOS settings?

1 Answer 1



Android phones are more brickable than PCs because they can hardly communicate with us if the bootloader is erased. And bootloader(s) live on Flash memory (eMMC) partitions which are prone to deletion quite easily (even during an update process). If you unluckily damage these partitions or they are worn out, there is a great chance you won't be able to communicate with device ever afterwards.
See Boot Process: Android vs. Linux and Android Device Partitions and Filesystems for details.


A device is considered bricked if we are unable to communicate with it. Now let's see how we communicate with devices at very lower level - say - when there is no Operating System installed or it gets corrupted/erased accidentally.


There is a standardization in PC world. BIOS is a mature firmware that provides a well developed platform to communicate with the system. It has ability to enumerate the hardware i.e. load basic hardware including motherboard, CMOS/NVRAM, RAM, hard drive, optical drive, graphics card and screen, keyboard, mouse, network card, and other peripherals connected to USB.
During Power On Self Test (POST), BIOS identifies all above said hardware by communicating at all internal and external buses whose paths are hard-coded with BIOS, sending them a signal like who is where?
UEFI - an evolution of BIOS - overcomes the limitations of 16-bit operation mode and maximum 1MB RAM usage. It's a minimal OS in itself which can even recognize and use filesystems, providing a better user interface, more configurable boot options and support for larger disk drives.

After this initialization of system, BIOS/UEFI reads bootsectors/bootloaders from bootable media like hard drives, USB storage or even network. It means that a PC is able to communicate with us even if there is no hard drive installed; it'll inform us: No bootable media detected. It's because BIOS/UEFI is stored on Electrically Erasable Programmable Read Only Memory (EEPROM that evolved from ROM, PROM and EPROM) connected to motherboard. If you somehow manage to erase or damage this EEPROM, yes your PC will also be bricked but that's rare.


Now coming to Android devices, hardware components are not connected to motherboard through buses, instead the core components that include CPUs, GPU, RAM, Flash/eMMC (equivalent of HDD or SSD), WiFi and bluetooth module, USB connectivity, UART (serial ports), JTAG (a very lower level serial communication protocol), GPS, modems (for cellular connectivity) are all built on a single System on Chip (SoC). Most of these components are not discoverable by SoC firmware (roughly equivalent of BIOS/UEFI) unless a Device Tree is loaded by final bootloader (e.g. ABOOT) into device memory i.e. just before kernel (OS) is loaded. And if you have no OS on the device, you are just depending on the minimal communication protocols provided by bootloader(s). At this stage only a few hardware components (usually graphics, NAND and some way of serial communication) are working, and that too with limited functionality.

Manufacturers may provide protocols at pre-bootloader or bootloader level e.g. Download Mode (QFIL / QPST / Qualcomm HS-USB QDloader 9006 and 9008 modes; PS: I don't know much about MTK or other SoC vendors), Fastboot, Odin etc. But these - Service Modes; what they call it - are disabled by OEMs for security reasons and as a part of their business strategies. Some manufacturers allow unlocking these service modes at user's risk after special approvals. Some hacks may also be used e.g. finding some test points on main board, shortening USB wires, using JIGs etc.
Lower level communication protocols e.g. JTAG are for development purpose only and those are almost impossible to be discovered and used for repairing purpose, though the same would have been possibly used for initial writing of firmware (including bootloaders) to flash memory. Some hacking tools like eMMC Flasher boxes/adapters may also use similar protocols for IMEI unlocking and other "black" stuff ;)
Also there have been successful attempts to boot Android from USB / UART ports but that's very rare now a days and requires a lot of technical knowledge and hacking skills.

All of these methods used to unbrick devices are not officially supported by most of the vendors, vary from vendor to vendor (not standardized) and are poorly documented for end user's usage.
That's why Android devices (or generally saying devices with embedded components) are more brickable than PCs.



See Also:

  • How did you know these info ? Where can i learn more in detail about what you just wrote ? Are there books that describes how to rewrite the eMMC ? Commented Nov 22, 2022 at 13:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .