723

• (edited )

Why you should probably unlock your phone's bootloader immediately after purchase.

In the past, I used to be afraid of touching the bootloader of a fresh, shiny and new device,but now I know that it was a foolish decision not to.

Over time, I have learnt that it might have been a smarter choice to unlock that shitty bootloader, because the locked bootloader has brought me many headaches over the past few years.

And to hell with warranty and “freshness” of the device.

Freedom and functionality

Google solicits users to root their devices through .

Many missing software features, new software restrictions and flawed behavioual changes can be retrofitted/bypassed/corrected through third-party software.
But that third-party software often relies on root access.

Obviously, rooting is not a solution for hardware flaws such as irreplaceable batteries that were brought to the market by slimtard iSheep who pushed their agenda (favouring slim design over functionality and modularity).

But at least, rooting gives users software-side freedom.

Data lock-in

Data lock-in means lack of data portability.

Data that is trapped by data lock-in can not be backed up.

Some apps, especially system apps, are notorious for storing app data in their private folder (under /data/), where they are inaccessible to other software.
Many of such apps also lack native exporting functionality (e.g. the precluded SMS and phone book apps).

Another app that traps data into the private folder is Samsung's S Browser: It stores saved pages, bookmarks, history and session inside its own private folder (ˋ/data/com.sec.android.app.sbrowserˋ), and because system apps are inaccessible through the Android Debug Bridge (ADB backups), and there is no export functionality, the data (most importantly the saved pages and bookmarklets) are trapped there.
Chrome stores saved pages as MHTML in the download folder, which is significantly better.

Unlocking the bootloader inevitably results in a factory reset, also known as a wipe, which prunes all user data, which would defeat its purpose if the user already has data trapped on the device.

Also, forget about forensic methods of retreiving trapped data:

Since Android 6.0 Marshmallow, full-disk encryption is enabled by default.
Even if it were not: One usually doesn't have access to such forensic tools, and not the know-how of how to use them. I certainly don't. And professional labs would be very expensive.

Trapped data can only be viewed through the device, and only as long as the device works.
If necessary components of the device fail, that data is in oblivion.

There might be some heavy workarounds to backup individual pieces of data, but no straightforward way for all bytes of data (disk imaging).

Also, with root access, a self-made shell script running inside the Android Terminal can automatically create regular timestamp-filenamed backup copies of the usually limited browsing history file, so one can have an infinite browsing history, i. e. no more websites one merely remembers but can't find.

Disk imaging

Without root access, disk imaging is not possible.

Disk imaging allows capturing an image of every sector of the mobile device's flash storage, so that the exact state of the device's internal storage can be straightforwardly restored at any later point.

This means that one can do experiments without fearing to break something, because it can be recovered all at once anyway!

With a full disk image, one can have the confidence that one can undo their operating system at any time.

A disk image is a straightforward full backup.

Undoing updates

Root access makes you immune against .

In , useful functionality was removed during the last few months:

List tab view (shows both title and URL + more items on screen)
Ability to deactivate the annoying pull-to-refresh feature.

Since around Android 3 or 4, downgrades of apps through APK's are prevented by the system.
But with root access, one can just downgrade and think: * I'll just downgrade! Nice try ruining my browsing experience, David Trainor!*

If there is anything I have forgotten to mention, or questions, feel free to write it in the comments.

Mass-storage access

MTP is unreliable and deprecated technology from 2004.

It is used because mass storage would require file-system-level access by the computer, which makes it vulnerable to file system corruption and would technically require exclusive access to avoid information from changing in a way they would deviate from the information cached in the computer's RAM.

However, MTP has serious flaws:

Random indefinite freeze-ups on Windows. Linux Mint handles MTP significantly more stable, but still occasionally spits out errors such as , , unable to get file handle , , or similar.
No parallelism: You can not browse files and watch videos from the device while data is being transferred in the background. All read and write access needs to be queued. Linux Mint's file manager does so smartly: It apparently prioritizes shorter actions (e.g. loading file lists while files transferred in backgtround after the current file has finished) instead of putting all actions at the end of the queue like Windows does _(wait until all files have finished transferring, then load file list)_.
Loading a long file list (e.g. when opening your camera folder or initiating the transfer of many small files) often takes longer than the file transfer itself.

Root access allows temporarily giving the computer exclusive mass storage access to the phone's internal memory.

What about _eFUSE_ and Samsung Knox, etc. ?

eFuse is indeed a invention.

But for those things, one could use a secondary, lesser expensive phone that still fulfills that purpose.

I believe that warranty should not be affected by software changes, but be restoreable when re-locking the bootloader. But these hardware triggers are more of an -like idea.

Feel free to share your thoughts in the comments.

If I have forgot to mention something, please also comment it.

In the past, I used to be afraid of touching the bootloader of a fresh, shiny and new device,but now I know that it was a foolish decision not to. Over time, I have learnt that it *might* have been a smarter choice to unlock that shitty bootloader, because the locked bootloader has brought me many headaches over the past few years. And to hell with warranty and *“freshness”* of the device. # **Freedom and functionality** Google solicits users to root their devices through [removed features and added restrictions](https://archive.is/20191014/https://en.wikipedia.org/wiki/Draft:List_of_features_removed_from_Android). Many missing software features, new software restrictions and flawed behavioual changes can be retrofitted/bypassed/corrected through third-party software. But that third-party software often relies on root access. Obviously, rooting is not a solution for hardware flaws such as irreplaceable batteries that were brought to the market by slimtard iSheep who pushed their agenda (favouring slim design over functionality and modularity). But at least, rooting gives users software-side freedom. # **Data lock-in** *Data lock-in* means lack of data portability. Data that is trapped by *data lock-in* can not be backed up. Some apps, especially system apps, are notorious for storing app data in their private folder (under */data/*), where they are inaccessible to other software. Many of such apps also lack native exporting functionality (e.g. the precluded SMS and phone book apps). Another app that traps data into the private folder is Samsung's S Browser: It stores saved pages, bookmarks, history and session inside its own private folder (ˋ/data/com.sec.android.app.sbrowserˋ), and because system apps are inaccessible through the Android Debug Bridge (*ADB* backups), and there is no export functionality, the data (most importantly the saved pages and bookmarklets) are trapped there. Chrome stores saved pages as MHTML in the download folder, which is significantly better. Unlocking the bootloader inevitably results in a factory reset, also known as a *wipe*, which prunes all user data, which would defeat its purpose if the user already has data trapped on the device. Also, forget about forensic methods of retreiving trapped data: * Since Android 6.0 Marshmallow, full-disk encryption is enabled by default. * Even if it were not: One usually doesn't have access to such forensic tools, and not the know-how of how to use them. I certainly don't. And professional labs would be very expensive. Trapped data can only be viewed through the device, and only as long as the device works. If necessary components of the device fail, that data is in oblivion. There might be some heavy workarounds to backup individual pieces of data, but no straightforward way for **all** bytes of data (disk imaging). Also, with root access, a self-made shell script running inside the Android Terminal can automatically create regular timestamp-filenamed backup copies of the usually limited browsing history file, so one can have an infinite browsing history, i. e. no more websites one merely remembers but can't find. # **Disk imaging** Without root access, **disk imaging** is not possible. Disk imaging allows capturing an image of every sector of the mobile device's flash storage, so that the **exact** state of the device's internal storage can be straightforwardly restored at any later point. This means that one can do experiments without fearing to break something, because **it can be recovered all at once anyway!** With a full disk image, one can have the confidence that one can undo [fucking up](#spoiler) their operating system at any time. A disk image is a straightforward full backup. # **Undoing [shitty](#spoiler) updates** Root access makes you immune against [rogue updates that make things just worse](/s/lostfeatures). In [Google Chrome](https://poal.co/s/LostFeatures/135974), useful functionality was removed during the last few months: * List tab view (shows both title and URL + more items on screen) * Ability to deactivate the annoying *pull-to-refresh* feature. Since around Android 3 or 4, downgrades of apps through APK's are prevented by the system. But with root access, one can just downgrade and think: *[Fuck you,](#spoiler) I'll just downgrade! Nice try ruining my browsing experience, David Trainor!* If there is anything I have forgotten to mention, or questions, feel free to write it in the comments. # **Mass-storage access** MTP is unreliable and deprecated technology from 2004. It is used because mass storage would require file-system-level access by the computer, which makes it vulnerable to file system corruption and would technically require exclusive access to avoid information from changing in a way they would deviate from the information cached in the computer's RAM. However, MTP has serious flaws: * Random indefinite freeze-ups on Windows. Linux Mint handles MTP significantly more stable, but still occasionally spits out errors such as *, , unable to get file handle , ,* or similar. * No parallelism: You can not browse files and watch videos from the device while data is being transferred in the background. All read and write access needs to be queued. Linux Mint's file manager does so smartly: It apparently prioritizes shorter actions (e.g. loading file lists while files transferred in backgtround after the current file has finished) instead of putting all actions at the end of the queue like Windows does _(wait until all files have finished transferring, **then** load file list)_. * Loading a long file list (e.g. when opening your camera folder or initiating the transfer of many small files) often takes longer than the file transfer itself. Root access allows temporarily giving the computer exclusive mass storage access to the phone's internal memory. # **What about _eFUSE_ and Samsung Knox, etc. ?** *eFuse* is indeed a [shitty-ass](#spoiler) invention. But for those things, one could use a secondary, lesser expensive phone that still fulfills that purpose. I believe that warranty should not be affected by software changes, but be restoreable when re-locking the bootloader. But these hardware triggers are more of an [Apple](/s/crApple)-like idea. ---- Feel free to share your thoughts in the comments. If I have forgot to mention something, please also comment it.