This is an old revision of the document!
| Good quality/price ratio
3 Gb RAM
| Complex rooting procedure
MIUI O.S. filled with bloatware
Non replaceable battery
|Internal Memory||32 Gb|
|CPU||Octa-core 2.0 GHz Cortex-A53|
|Screen||5.45 inches, 720 x 1440|
|Audio jack||3.5 mm|
|MIUI Version||Global 10.3 Stable 10.3.2.0 (OCGMIXM)|
|A/B (Seamless) System Updates|| No. Blank result at command:
fastboot getvar current-slot
|Anti-Rollback Protection|| No. Blank result at command:
fastboot getvar anti
Unfortunately this Xiaomi phone has a very annoying procedure to unlock the bootloader: it is mandatory to execute an on-line procedure using a PC running an MS-Windows program, on the phone you have to enable the mobile internet connection (thus requiring a valid SIM card) and execute an app which will collect several data from the phone (ID CPU, IMEI, IMSI etc.). Once you start the procedure, you will be granted the right to unlock the bootloader, but with a wait time of several days. In my case the delay was 358 hours (about 15 days).
At the first run - once added a Google account and activated a WiFi connection - the phone suggested to update the operating system; the proposed update was MIUI V10.2.6.0.OCGMIXM Stabile 638 Mb. The upgrade failed: the download phase was plagued by error messages like L'app Google continua a interrompersi (Google App Keeps Stopping) and similar messages from other apps. Once downloaded the upadte, the phone rebooted. On the black screen there was the message Aggiornamento MIUI in corso, non riavviare il dispositivo, then an error message informed that the upgrade failed. The phone rebooted and a popup informed that the upgrade failed, suggesting to retry the ROM download.
At the second try, the system suggested to download the update MIUI V10.2.6.0.OCGMIXM Stabile 1.2 Gb (notice 1.2 Gb, instead of 638 Mb of the previous run). This run completed successfully, the system is:
|Android Version||8.1.0 O11019|
|MIUI Version|| MIUI Global 10.2 Stable
Once upgraded the ROM, the phone started to download all the updated apps. In this phase the Play Protect warned about an harmful application Font Manager, which was removed (App dannosa rimossa, Harmful app removed).
Running the Mi Unlock Status will show you several warning messages. It is required that WiFi is disabled and an internet mobile connection is available (so you need a working SIM card). Tapping the button Aggiungi account e dispositivo (Add account and device) you will be guided into a procedure to create a Mi account. A verification code will be sent via an SMS message.
Running this procedure have created your Mi account and have created a request to unlock your Xiaomi device, both will be used on a PC running MS-Windows and the Mi Unlock program.
The smartphone (bootloader) is still locked, you can check the status running the adb and fastboot programs on the PC, while the phone is connected via the USB cable (you have to grant USB permission via the phone pop-up):
adb reboot bootloader
wait untill the fastboot logo appears on the phone, then:
fastboot flashing get_unlock_ability ... (bootloader) unlock_ability = 0 OKAY [ 0.000s]
You need to have an account on the MiUi site (created on the smartphone, see above), then you have to install and execute the Mi Unlock program on a MS-Windows PC. Beware that we are running a program downloaded from an untrusted source and we don't have the source code to inspect. Every evil thing is possible, on your PC and on your smartphone! Run at your risk.
Unfortunately Xiaomi has introduced a very nasty temporal block: when you ask for phone unlock using the Mi Unlock Status on the phone, you will get a time to wait, in my case it was 358 hours, so the program on the PC failed with the following message: Couldn't unlock. A message in very bad English says: After 358 hours of trying to unlock the device.
After 15 days I repeated the above procedure from step 6. It failed a couple of times perhaps because I forgot to put the same SIM into the phone or may be because I used a different version of the Unlock program. Eventually I succeded into getting the bootloader unlocked.
The phone got a factory reset, once rebooted I repeated the procedure to enable the Developer options (Opzioni sviluppatore). It was also necessary to enable again Debug USB and Debug USB (impostazioni sicurezza). I finally confirmed that OEM Unlock is actually unlocked (Sblocco OEM ⇒ Il bootloader è già sbloccato) and that Mi Unlock Status is also unlocked (Stato Mi Unlock ⇒ Sbloccato).
After OEM Unlock, before flashing the TWRP Recovery, the phone received another OTA Update. We passed several phases: download, veryfy, reboot, install. The install procedure freezed at 74.49%; after a long pause it eventually rebooted into the updated system. At the end of the upgrade the system is:
|Android Version||8.1.0 O11019|
|MIUI Version|| MIUI Global 10.3 Stable
When you run the TWRP Recovery for the first time, you can install Magisk. It provides the su program, the actual super-user command, and the Magisk Manager, the app which manages root permissions. We downloaded the Magisk-v19.1.zip file from the GitHub releases page (4.7 Mb, md5sum 1205486d9302e2e8ea03d67bd1f67aa3). We copied the file to the /sdcard directory of the phone.
NOTICE: Does not know if it matters: I don't have cryptography enabled on the phone. I think that this will easy any action performed from recovery. From phone settings: Impostazioni ⇒ Impostazioni aggiuntive ⇒ Privacy ⇒ Crittografia e credenziali ⇒ Crittografa il dispositivo usando la password della schermata di blocco (disabled).
The official TWRP is downloadable from https://dl.twrp.me/cereus/. There are several recipes on the net for installing TWRP on the Redmi 6, it should be as easy as entering fastboot mode on the phone and executing on the connected PC:
fastboot flash recovery twrp-3.3.0-0-cereus.img fastboot boot twrp-3.3.0-0-cereus.img
Unfortunately the phone boots into normal system, not into Recovery. If you start Recovery (power down, VolumeUp + Power until the Mi logo is shown), you enter the stock Mi-Recovery 3.0. It is very likely that flashing went OK, but during the bootstrap the recovery is automatically restored to the stock one.
NOTICE: The key difference of this recipe seems to be flashing two partitions: the one name recovery with the actual TWRP image and the one named para, with dummy data.
We found this post on the net: LR.Team 3.3.0 TWRP Redmi 6 Custom Recovery. This custom recovery is provided by a Chinese team, here the original post. The program starts in Chinese language, fortunately you can switch to English by clicking a button.
This recipe states to flash two partitions: the regular recovery plus a partition named para. This second partition is flashed with a little image called misc.bin. It seems that flashing this second partition (which actually is a fake file, it does not contain any code) is the necessary trick to prevent automatic restore of the recovery partition.
Once started the phone in fastboot mode, we ran this from the connected PC:
fastboot flash recovery recovery-TWRP-3.3.0-0423-REDMI6-CN-wzsx150.img fastboot flash para misc.bin fastboot boot recovery-TWRP-3.3.0-0423-REDMI6-CN-wzsx150.img
In this way we succeeded in starting TWRP recovery. In the first run we did not make any action in TWRP, just rebooted. It turned out that installation of TWRP was not permanent, at the following attemp to start recovery (via adb command) we found again the sotck Mi-Recovery 3.0.
So we decided to exactly follow the instructions step by step:
NOTICE: The LR.Team TWRP image contains Magisk 19.0 (unpack the img file and extract the ramdisk content, you will find a
/supersu/SuperSU_installer.zip file, which actually is Magisk). This is the default root method, and it is executed inside TWRP with the Install Root title. May be, for this reason, installing Magisk 19.1 is not strictly required.
NOTICE: Some recipes on the net say to flash also LazyFlash or some other DM Verity Disabler tool. It seems that it is not longer require with Magisk 19. Infact, during Magisk installation, we read a log line stating Removing dm(avb)-verity in dtb (see
/common/boot_patch.sh of the SuperSU_installer.zip file). By the way, the LR.Team TWRP image contains also the
/supersu/no-verity-opt-encrypt.zip file into the ramdisk image, which actually is the LazyFlasher installer.
NOTICE: It seems that flashing the para partition is a non-permanent action. If you want to boot into another recovery from the fastboot mode, you have to flash it again witht the dummy misc.bin.
Sometimes the /sbin/su command disappears. It happened after a system crash (trying to remove one system app via Titanium Backup) or after a simple system reboot, or doing a reboot from TWRP menu. Fortunately enough, it was sufficient to reboot into TWRP Recovery and reinstall Magisk-v19.1.zip.
Wishing to have the official TWRP image instead of an unofficial one, I used the previous method substituting the LR.Team image with the official one from TWRP (twrp-3.3.0-0-cereus.img). The TWRP official image were flashed, but the result was un unbootable system! Even booting in fastboot or recovery were problematic, because I got a black screen after the “Mi” logo regardless the key combination pressed at boot time.
After several blind tries, the TWRP screen eventually appeared! Perhaps the right keys sequence was: power off, VolumeUp + Power, wait one minute, then VolumeDown + Power). Fromt the TWRP menu I fortunately booted in fastboot mode and re-flashed LR.Team image.
Now, at each reboot, we receive a warning message: Sistema Android - Si è verificato un problema interno con il dispositivo. Per informazioni dettagliate, contatta il produttore. The English version of the message should be There's an internal problem with your device. Contact your manufacturer for details. We are still investigating how harmful is that message.
The solution in this post does not apply because values of keys ro.build.date, ro.build.date.utc and ro.build.fingerprint are the same in files /system/build.prop and /vendor/build.prop.
The problem seems neither be related to the following line in /system/build.prop:
Using the bootimg-id tool we calculated the ID of the custom TWRP recovery, which is different (0xb843c727d388c4283be9b233d2353c69805487c0000000000000000000000000), but fixing that line did not solve the warning message at boot. NOTICE: to change permanently the /system/build.prop file, we operated in TWRP recovery: first mounting the /system partition in read/write mode, then running a TWRP terminal session and replacing that file with a new one. This was required because every modification to the /system partition performed via an adb shell, is lost after a reboot.
I still have big problems on my Redmi 6: su is working, but every change to the /system partition is lost/reverted on reboot. This behaviour does not exist in another phone (Xiaomi Mi A1), despite they are both running TWRP and Magisk. Versions tested are TWRP 3.2.1 and Magisk 17.3 on the working Mi A1 and TWRP 3.3.0 and Magisk 19.1 on the problematic Redmi 6. To make permanent changes to the /system partition, I need to use a terminal session from TWRP Advance menu.
Once you got root privileges on the phone, you can modify everything on it, even the /system partition which contains the so called ROM (which is not actually a read-only memory, but a filesystem hosted into a read/write memory, mounted in read/only mode).
In the old days, you just have to mount -o remount,rw /system and make any changes you like, but if you installed a recent version of Magisk, it used a systemless root method. It's essentially a way to modify the system without actually modifying it. Modifications are stored safely in the boot partition instead of modifying the real system files. This is the most important feature of this tool. Since the original system files remain unchanged, modifications can go undetected by Google SafetyNet and other verification methods (used e.g. before installing OTA updates).
The bottom line is: any change you make to the /system partition, does not survive a reboot. To make a permanent change you have to write a Magisk module following this guide. Actually a module does not change the /system partition, but it contains the modifications that will be merged into the /system partition on each bootstrap.
You can also modify the /system partition when the phone is running the recovery program. For example, if you have installed the TWRP Recovery, you can mount the /system partition in read/write mode (from Mount menu) and execute a terminal with root privileges (from Advanced menu). Every modification to the /system partition will be permanent: beware that this may break SafetyNet checks performed by some applications or break OTA upgrades.
Unfortunately I have not yet found a way to remove such software, but it seems that it is possible to disable it. Here it is a list of our tries.
The first try was to simply delete the app folders via adb shell, something like this:
su mount -o remount,rw /system rm -r /system/app/MiuiVideoPlayer rm -r /data/data/com.miui.videoplayer mount -o remount,ro /system
Surprisingly, afer a reboot, the directories were restored with their original contents. Every change to that directories is simply reverted once rebooted. This is probably related to the way Magisk handles tmpfs overlay (and Magic Mount), the way used by Magisk to hide himself from detection.
The Android operating system provides the pm Package Manager command, (here a nice cheat-sheet). Using root permission on the command line, you can list all installed packages and disable some of them:
# List all installed packages pm list packages # Disable a package: pm disable com.miui.calculator # List disabled packages pm list packages -d
When you disable some packages, the associated icon disappears immediately from the Miui launcher. It seems that disabled state persist across reboots. I disabled all of the following (apps replaced by others from Google Play or F-Droid):
|com.miui.videoplayer||Mi Video player|
|com.xiaomi.scanner||Scanner (QR Code)|
|com.miui.gallery||Images Gallery (this one is re-enabled automatically)|
Here are some settings concerning privacy, notifications and automatic updates.