Ever since in 2014 I published a post on XDA for my smartphone Oppo Find 7, concerning the unlocking of the bootloader and the repartitioning of some partitions of the above-mentioned Android smartphone, I became convinced that unlocking the bootloader is a double-edged sword, that is, if it is properly used it can bring benefits, if not properly used it can bring just so much trouble. On this page I will try to describe the pros and cons of unlocking the bootloader, both as a programmer and as an end-user. Before going into the bootloader unlocking procedure, let's take a look at the storage of an Android smartphone device and the ADB/Fastboot commands, to which I dedicate the following two paragraphs. This is because, it seems strange, many users that are going to unlock the bootloader, have no idea what they are going to do, they simply use the bootloader unlock procedures for their Android device by taking them from the Internet, without knowing what they are doing and how they do it, with everything that implies.
To understand how an Android device works, we must have a basic understanding about the internal storage of the Android device. The internal
storage of an Android device, commercially called improperly ROM (improperly because the acronym ROM stands for "Read Only Memory" - the internal storage is
also a writable memory as well as readable - moreover there is confusion with the term ROM used instead of the term firmware), it consists of a solid state disk
drive, called eMMC (Embedded MultiMediaCard) or, in more recent or expensive devices, UFS (Universal Flash Storage) and represents the only internal storage
drive of an Android device. So, it is the equivalent, as performance, of a Solid-State Drive (SSD) that is used as storage for computers, NAS and other
electronic devices. In an Android device this storage is partitioned, i.e. various partitions are created on it, each with a well-defined name, which define a
significant part of the Android software/hardware system. As we will see later, part of the negative factors of unlocking the bootloader has to do with
partitioning storage. The care and preservation of the partitions of an internal storage, in an Android device, are handled by the manufacturing companies (if
the bootloader remains locked) or by the end-user (if the bootloader is unlocked).
As an example Android device, I take the old OnePlus One, more for simplicity than anything else, the most modern devices have many more partitions, if not even
the division of storage into multiple parts (each part will be seen as logical/physical unit, however each unit will be divided into partitions).
To see the list of partitions, two methods are used which must be put together as a puzzle. The first method consists of viewing the "/proc/partitions"
file inside a terminal, using the ADB Shell (see the next paragraph for the ADB/Fastboot commands). This file is not always accessible to the end-user, anyway I
provide an example to understand how internal storage is partitioned. Here is the output of the "cat /proc/partitions" command of my OnePlus One device:
major minor #blocks name
179 0 61071360 mmcblk0
179 1 65536 mmcblk0p1
179 2 512 mmcblk0p2
179 3 32 mmcblk0p3
179 4 32 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 500 mmcblk0p6
179 7 16384 mmcblk0p7
179 8 500 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1536 mmcblk0p10
179 11 1536 mmcblk0p11
179 12 10240 mmcblk0p12
179 13 10240 mmcblk0p13
179 14 1355776 mmcblk0p14
179 15 32768 mmcblk0p15
179 16 524288 mmcblk0p16
179 17 16384 mmcblk0p17
179 18 1536 mmcblk0p18
179 19 1 mmcblk0p19
179 20 8 mmcblk0p20
179 21 1024 mmcblk0p21
179 22 16384 mmcblk0p22
179 23 32768 mmcblk0p23
179 24 32768 mmcblk0p24
179 25 16384 mmcblk0p25
179 26 8192 mmcblk0p26
179 27 65536 mmcblk0p27
179 28 58510540 mmcblk0p28
179 29 294895 mmcblk0p29
179 32 4096 mmcblk0rpmb
The second method is to view the contents of the "/dev/block/by-name" folder, this folder should be visible to any user. Here is the output of the "ls -l /dev/block/by-name" command:
total 0 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 DDR -> /dev/block/mmcblk0p4 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 DRIVER -> /dev/block/mmcblk0p23 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 LOGO -> /dev/block/mmcblk0p22 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 aboot -> /dev/block/mmcblk0p5 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 boot -> /dev/block/mmcblk0p7 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 cache -> /dev/block/mmcblk0p16 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 dbi -> /dev/block/mmcblk0p3 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 fsc -> /dev/block/mmcblk0p19 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 fsg -> /dev/block/mmcblk0p18 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 grow -> /dev/block/mmcblk0p29 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 misc -> /dev/block/mmcblk0p21 lrwxrwxrwx 1 root root 18 1970-02-09 03:31 mmcblk0 -> /dev/block/mmcblk0 lrwxrwxrwx 1 root root 22 1970-02-09 03:31 mmcblk0rpmb -> /dev/block/mmcblk0rpmb lrwxrwxrwx 1 root root 20 1970-02-09 03:31 modem -> /dev/block/mmcblk0p1 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 modemst1 -> /dev/block/mmcblk0p10 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 modemst2 -> /dev/block/mmcblk0p11 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 oppodycnvbk -> /dev/block/mmcblk0p12 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 oppostanvbk -> /dev/block/mmcblk0p13 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 pad -> /dev/block/mmcblk0p9 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 persist -> /dev/block/mmcblk0p15 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 recovery -> /dev/block/mmcblk0p17 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 reserve1 -> /dev/block/mmcblk0p24 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 reserve2 -> /dev/block/mmcblk0p25 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 reserve3 -> /dev/block/mmcblk0p26 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 reserve4 -> /dev/block/mmcblk0p27 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 rpm -> /dev/block/mmcblk0p6 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 sbl1 -> /dev/block/mmcblk0p2 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 ssd -> /dev/block/mmcblk0p20 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 system -> /dev/block/mmcblk0p14 lrwxrwxrwx 1 root root 20 1970-02-09 03:31 tz -> /dev/block/mmcblk0p8 lrwxrwxrwx 1 root root 21 1970-02-09 03:31 userdata -> /dev/block/mmcblk0p28
Once we have these two outputs, we put them together to understand how many partitions there are and how they are called. If we consider that
"mmcblk0" is all the storage (in Linux it is called "block device"), inside we will have N partitions, which in the case of OnePlus One are 29, each of
it has a number – its range is from "mmcblk0p1" to "mmcblk0p29". This using only the first output. Using also the second output, we will also have
the name of each partition. So, the partition "mmcblk0p1" is called "modem", the partition "mmcblk0p2" is called "sbl1", and so on.
Keep this arrangement/naming of the partitions in mind, as it will be used in the next paragraphs.
Important note: as long as the bootloader is locked, the structure of the partitions cannot be changed, but only the content of some
partitions can be changed - this change cannot be made directly by the user, but only by the manufacturer through specific update procedures. Unlocking the
bootloader, on the other hand, directly provides the user with the possibility to change the structure of the partitions, in addition to their content, with all
that it involves both in positive as well as in negative terms.
An important part for those who are about to unlock the bootloader is the good knowledge and skill of two basic commands, such as "adb"
and "fastboot" (I write them in lowercase because they must be typed in this way inside a guest operating system). These two commands represent the real
interface of connection between an Android device and a guest device, which can be Windows or Linux. With these commands various operations are carried out, in
the specific case of unlocking the bootloader, the "fastboot" command is the most important. Obviously both commands are not supplied with the guest
operating system, since they are owned by Google, and represent what Google itself calls "SDK Platform Tools" ("SDK" stands for "Software Development
Kit"), since they are provided by Google with "Android Studio" (the Google compiler for creating Android apps). A copy of the "SDK Platform Tools"
can be found on the Google website at the following address.
My suggestion, before using these commands on a real, even expensive, Android device, is to practice on an Android virtual machine, for example a software
emulator. There are various types, for example Genymotion (for private users), or the same emulator included in the above-mentioned Google "Android Studio".
These tools allow you to create fully functional Android virtual machines, with the advantage of not doing damage on real Android devices. With virtual
machines, of course, you can practice with the "adb" command, unfortunately the "fastboot" command is more related to partitions and to unlocking the bootloader.
An Android device can be accessed using three modes.
As mentioned in the paragraph "Storage and its partitioning", until the bootloader is locked, there is no way for the user to directly modify
the structure of the internal storage partitions, therefore there is absolute certainty for the user to access the Android device using one of the three
above-mentioned modes. On the other hand, if the bootloader is unlocked, it is not only possible for the user to modify the content of the partitions of the
internal storage, but it is possible to modify the structure of the partitions; in the worst case, the three above-mentioned device access partitions may no
longer be accessible. In this case accessing the device is practically impossible, the user will be obliged to ask for device repair.
There is actually a fourth access mode, we can call it "emergency" (each manufacturer provides a different name for this procedure), and it is the one used by
the device manufacturer not only when the device is manufactured, but also when the device is sent by the user to the service centers to repair the device
itself. In this mode, the device is accessed via the USB cable and, with a proper software, the programming code of the internal storage is passed, via the
above-mentioned USB cable, in order to create the structure of the partitions and modify the content of the partitions. This allows the device to leave the
factory properly programmed so that it can be used by the end-user. This type of software, for enthusiasts of electronics, is similar, as a concept, to EEPROM
programmers, with the difference that a serial cable is not used to program an EEPROM (physically accessible to the user), but an USB cable (which effectively
is a serial cable) is used to program a solid state disk integrated in an Android device (in this case the disk is not physically accessible to the user).
Obviously the manufacturer is not obliged to provide the above-mentioned internal storage programming software, the manufacturer only is obliged to provide a
well-built product and to provide the user with this product in such a way that it can be used in the best possible way, without the possibility of damaging the
product, both respecting the terms of the warranty (we will discuss it in the next paragraphs).
When I got my Oppo Find 7 in 2014, I first made sure that this internal storage programming software existed, since the code I published heavily altered the
structure of the partitions, eliminating partitions to access the device and recreating them from scratch - this would have meant, if the code had been written
incorrectly, the inability for me to access the device again. So, the immediate possibility of having software for direct access to internal storage allows the
end-user to have a fourth possibility of access in the event that the first three modes are no longer usable.
My suggestion is obviously that you have to find out in advance if there is an emergency mode, obviously not from the manufacturer (I repeat it is not obliged
to provide it), but on the discussion forums in Internet. This emergency mode allows you to perform the unlock procedure of the bootloader in a safer and more
secure way.
The unlocking of the bootloader of an Android device is not only a subject of discussion on the Internet at a technical level, but first of all it is a subject of discussion in a purely legal context. The situation would seem tangled enough to make it chaotic, actually it is necessary to start from the so-called "agreement", i.e. the contract between the manufacturer and the end-user. Here the concept of "warranty" comes into play. In Europe and some other non-European countries, the warranty is 2 years, while in America, China and other countries the warranty is only one year. The manufacturer, through the contract, provides the user with what the user can do with the device (or the "product"), and what the user cannot do during the warranty period. The bootloader unlocking procedure normally does not fall into what the user can do with that product during the warranty period. Therefore, the user, even before purchasing an Android device, must ensure, through the contract, whether can perform the bootloader unlocking procedure without this procedure having to void the warranty. There are two cases:
The discussion in this context ends here since I'm not a lawyer. My advice is to examine this matter legally, with real lawyers, better if they are experts in contracts and in the digital domain. The legal implications of unlocking the bootloader could make this practice more and more forbidden by manufacturers in the future, since it represents one of the main reasons for device malfunction, especially if this practice is performed by inexperienced or unaware people.
The bootloader unlocking procedure depends on the Android device. In any case the bootloader unlocking procedure will delete all the data inside the device, the user is obliged to make a backup of all the data inside the device before performing the above-mentioned unlocking procedure. Furthermore, the user will obviously have to refer to the discussion groups on the Internet, for more information on how to perform the bootloader unlocking procedure safely and effectively. For example, in some devices you will have to:
Keep in mind that the bootloader unlocking procedure is forbidden not only by many Android device manufacturers (as per previous paragraph
"Warranty and legal implications"), but also by many Android app makers, for example it is forbidden by the apps of the banks, from the apps of virtual credit
card providers and it can also cause problems to Google’s "Google Pay" app.
Furthermore, the bootloader unlocking procedure makes the device no longer certified - this will be clearly visible within the settings page of the "Google
Store" app. The lack of certification is also related to the payment with virtual cards (also to Google’s "Google Pay" app), payment will be no
longer available until the device is certified again.
Make sure, within Internet discussion groups, if there are alternative methods to avoid all the above-mentioned problems, since the Internet forums are full of
complaints from angry users who, after performing the bootloader unlocking procedure, cannot pay anymore, for example by making shopping in physical stores,
using the device as a virtual card and/or via NFC.
In the past, the bootloader unlocking procedure was performed to achieve maximum performance from the internal hardware components of an
Android device, for example by overclocking the processor - considering that the processors a few years ago, in the Android environment, were so slower than
modern ones. Furthermore, this procedure was performed to have a more efficient version of Android, with more options, more versatile, or, in the case of
devices no longer supported by the manufacturer, to have updated versions of Android and no more outdated. In addition, unlocking the bootloader, even today, is
a mandatory procedure if you want to achieve the "root" privileges of the Android device.
Today we need to evaluate its effectiveness, but also the pros and cons. The ROMs (the firmware) provided by the manufacturer effectively are "Custom ROMs",
with many more features than the "stock" version of Android provided by Google. As always happens in the IT field, there are very different schools of thought.
There are users who do not want a "custom ROM", often heavy and full of unwanted features, but instead want a "stock" ROM, light, fast and efficient. On the
other hand, the opposite is also true. On the Android device market there are both devices with ROMs customized by the manufacturers, and "stock" ROMs always
supplied by the manufacturers with direct support from Google (i.e. "Android One" devices). In advance the user must make a choice since the locking of the
bootloader, as long as the device is under warranty, leads the user to not be allowed to alter the device. Things change if, after the warranty expires, the
user decides to move to another ROM, then unlocking the bootloader becomes the only solution and allows the user to no longer be constrained by the choice made
previously.
We must also consider the impressive technological progress of modern smartphones, which in some cases can compete with computers - do not forget that a
smartphone effectively is a portable computer. Very fast processors (CPU and GPU), advanced Wi-Fi/NFC/ Bluetooth functionality, more and more advanced cameras,
plus all the additional hardware features provided by the manufacturers and supported only by their own custom ROMs, often make the bootloader unlocking
procedure useless and even self-defeating - this without considering the legal implications that we discussed in a previous paragraph.
On the other hand, the bootloader unlocking procedure brings positive things. I think about the unbelievable amount of enthusiasts and experts in this field,
forums full of fans more and more present on the Internet, more and more Custom ROMs available and more and more people involved in their development,
maintenance and support. In addition, more and more companies work closely with these enthusiasts, working together all we get more results and the end-user is
increasingly happy and productive, this brings benefits both to device manufacturers and to the end-user who is more and more loyal. In addition, the same
companies know that even after the end of their devices’ support, the most skillful and aware users will not have to change the device but can upgrade it simply
by performing the bootloader unlock procedure and putting an alternative ROM, still effective and equal to that previously provided by the manufacturer. This
detail will no longer lead to a rapid obsolescence of the products, which will therefore live longer, with all the positive repercussions both in the
environmental and social/economic contexts - in times of economic stringency this is a real boon.
After examining in the previous paragraphs all that is needed at a technical and legal level to perform the bootloader unlocking procedure and having evaluated its effectiveness but also its pros and cons, we can draw the conclusions. My suggestion is always the same; as a technology enthusiast since the 80s, I recommend performing the bootloader unlocking procedure only if strictly necessary (and in any case after the warranty is expired), having excellent knowledge of your device and having excellent knowledge of the tools to perform the above procedure - the basic rule is always "if you don't know what you're doing, don't do it". And first of all, use your own brain, avoiding listening to the suggestions of those who always make it so easy, without therefore considering the possible and imaginable repercussions on performing this kind of procedure. Remember that each product has its own value; if you've spent so much money on a product, always ask yourself if it's worth damaging it and why you should do it. Today the time is ripe, hardware and software become more and more complete and complex, today the end-user, in the Android context, has a wide choice, and can choose the best product based on budget and needs.