LineageOS on Doogee Smini (or any other android)

It's been some time since I bought the Cubot KingKong Mini 2. It's been working pretty well all these years, but the battery life is not so good any longer, the phone is scratched from all sides, modern android apps are quite often very slow (e.g. windy is almost non-usable,...). So it's time to get a new phone, but which one? I quite got used to the small form factor of a 4 inch phone. The small android phones market is still as small as it was few years ago. There are only few phones below 5 inches and they all are quite similar when it comes to dimensions.

Cubot KingKong Mini 3 is taller and the screen is more narrow than on the Mini 2. What the hell? The main issue of the Mini 2 was a narrow screen (hard to type precisely), make it few mm wider, put there a better camera and you would have the best mini phone out there... Aside from the insane screen ratio, the camera is still pretty bad and specs are still quite crappy... On the bright side, there are reports of custom ROMs running well on this phone.
Blackview N6000 follows the same path of the Mini 3, it's tall and narrow. And way too thick. I've bought it and send it back after unpacking, the thickness is quite crazy. For some reason, someone thought it's good idea to make the display notched for the front camera, although there's a plenty of space around the screen. Aside from that, it's a nice phone which would withstand a nearby atomic blast. But the weight and thickness makes it a huge brick although the other dimensions are ok...
Doogee Smini again follows a trend of narrow and tall screens (which makes no sense), but it's almost as thick as the Mini 2, weights about the same and it's only a slightly taller. The specs are quite nice, although it still doesn't support the 5G networks, but who cares, I don't use the phone to stream GB of data over a network. And for some reason, it has a second, completely useless display on the back (which is a second main disadvantage (right after screen width) from my point of view).

The Smini looked best from the phones I've found, but there were only few reviews and no discussion of xda, so I've ordered it, hoping it will look and work nice, without knowing if it could be rooted and if any unofficial firmware would work on it. It was a bit risky step as I refuse to use anything that runs google services or is not under my complete control. There were no mentions on the internet about rooting or flashing this phone, the firmware was not available anywhere, so the chances were quite low. So inhale deeply and follow my quest of rooting and flashing this beast.

First impressions

The phone is a bit taller than the old King Kong Mini 2 and a bit thicker, as a result, the phone feels heavier and won't fit my hand as good, but the size is still ok. The narrow screen is weird, adding few mm to width instead of height would be better... The system is quite fast and responsive, the camera is ok, the second screen is pretty useless as it shows only the data downloaded from the internet.

Pros:

looks sturdy and durable
screen protection screen installed by vendor
notification diode
sim card can be replaced without a screwdriver
decent camera with very fast response time (I'm looking on you KKM2)
all the bells and whistles of the modern phones - NFC, GPS/Glonass/... Face unlocking, fingerprint sensor - in a cheap and small package
decent specs (8GB RAM, 256 GB flash, fast Helio G99 CPU)
USB-C with a rubber protection cover
pretty recent Android 13 on stock ROM with very low bloatware level
Pretty loud speaker (although the quality is not the best)
sensitive GPS/others sensor

Cons:

second sim is shared with SD card slot
useless second screen (shows data downloaded from internet, not measured locally)
idiotic screen ratio, it would be much better to make it wider, not higher...
bigger, heavier and clumsier than my old KKM2, but still the smallest reasonable android out there
non-complete language translation of the stock android, random english appearing once in a while when browsing the system settings

phones

Verification

To see if flashing this phone was even remotely possible, I've done several steps:

Asked Doogee for the firmware files for my phone, the response was quick and I've got all the files (system.img, boot.img, vbmeta_system.img, scatter, etc.). The Czech firmware version is available here if anyone is interested. Thanks to this, I have a good way to resurrect my device if I happen to brick it.
Verified if the device fully supports Project Treble by this App. It also gives some more details about the partition scheme (legacy, A/B,... see below for more details). The Smini is Project Treble compatible and it uses an A/B partition scheme.
Checked if the bootloader unlocking is possible: Settings->Phone info and tap several times on the Build number, now in Settings->System->For Developers check if Debug over USB and Bootloader (OEM) unlock can be enabled.

So, it seems it won't be that hard after all, I have the factory firmware files, the phone supports Project Treble, has A/B partition schema and bootloader unlock seems to be possible.

Backup

It's a good custom to make a backup of the phone before actually changing anything so there's a way back in case of any issues, e.g. when the phone refuses to boot the custom ROM and you decide to give up and return the phone back to the seller within the 14 days for refund (it's possible in Europe). Also the user data partition gets wiped (factory reset) during the process, no problem for me (brand new phone), but a huge problem for anyone who was using the phone for a while - don't forget to backup your data!

The MediaTek based phones can be backed up in few ways:

The mtkclient tool. It's a pretty powerful tool that can even unlock the bootloader when unlocking is not supported by vendor. However the G99 (MT6789) SOC is not fully supported yet and I was only able to read some basic phone information before it throw an error. If anyone's interested, the backup process is:
- Run python mtk rl --skip userdata <folder_to_put_backupt_to> (user data are skipped - way too huge)
- Power off the phone, then press and hold volume up and down while connecting the USB cable
- Wait for backup to be finished
The SPFlashToolV6 is an standard way to write and read firmware of the MTK base phones, it requires a scatter file (partition map). It can be usually found on the internet, or in our case, it was provided as part of the binary released by the vendor - MT6789_Android_scatter.txt. I was able to configure the tool to flash the vendor provided firmware files, but the readout was somewhat broken and I was too lazy to dig deeper.
The adb tool can be used to dump the block device from the phone directly, but a root is required, so this won't work in our case. But just for your information, run e.g. adb pull /dev/block/platform/soc/11270000.ufshci/by-name/boot_a ./

The huge advantage of modern android phones with A/B partition map is that you can damage one of the partition in any way and the phone will still boot from the second one with the stock firmware. And as I had no luck after a hour or so of trying to dump my partitions, I gave up and started experimenting without backup (I was not that worried after obtaining factory image from vendor).

Flashing

Preparation

The flashing process is quite straightforward, similar to most of the MediaTek based devices:

Install the necessary android tooling to your PC - fastboot and adb is needed. It's usually available in a package manager. If you are running windows, get a better OS or live the pain of installing all the USB drivers and other stuff downloaded from random places on the internet.
- Unlock the bootloader - without this step, it's much harder or even impossible to flash custom partitions.
- Enter Settings->Phone info and tap several times on the Build number, now in Settings->System->For Developers allow Debug over USB and Bootloader (OEM) unlock
- Connect the phone to the PC, accept authorization of the PC on your phone and reboot to bootloader by running adb reboot bootloader
- Unlock the bootloader by running fastboot flashing unlock and pressing volume up on phone to confirm the process - this will wipe all the user data!
- Eureka, you have your bootloader unlocked, the phone will now report Orange state on every boot and hang there for 5 seconds. And you have invalidated your warranty, btw.

See what slot is currently active by fastboot getvar current-slot and optionally switch to a different slot by running fastboot --set-active=a
Flash vbmeta partition to disable the rom integrity checking, either use the generic image from google or use the image from vendor provided firmware files
- fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
- The command above shall write to the selected slot - either vbmeta_a or vbmeta_b, but the smini bootloader is a little fishy, it has always written to vbmeta_a for me, regardless of the active slot.
- The Smini bootloader has few bugs, when it stops talking to you (fastboot command hangs), just disconnect the USB cable and connect again.
- The vbmeta shall probably be flashed from fastbootd mode (part of recovery firmware), but for some reason, the fastbootd on smini always fails with File doesn't exist when writing anything else than system partition.
- If the flashing still fails, try running adb reboot bootloader and fastboot reboot fastboot, the phone sometimes enters a strange fastboot mode that worked everytime for me when flashing the vbmeta.img

Now the phone shall accept any modifications to system, boot and other partitions without bootlooping. If you messed up something, it shall boot up the factory firmware stored in a second slot (if there's any) - happened to me few times...

Rooting

There are basically two options how to root the phone:

Install rom that already contains the su binary and some app that would manage access to this binary.
Use magisk to patch the boot.img and flash this modified image.

The magisk is a pretty standard way to root your phone, it not only provides a root access to your apps, but it's also able to hide itself and the fact the phone is rooted from rest of the system, which is quite handy if you banking app is way too picky about the security and has no opt-out for rooted phones... The process is simple:

Take the boot.img from vendor provided firmware files (or dump it from your phone if you manage to - see the backup section above) and push it to your phone: adb push boot.img /storage/emulated/0/DCIM/
Install the magisk app (use the app directly downloaded from github, that's the only legit one out there)
Patch the boot.img binary in the magisk app
Pull binary back to your pc: adb pull /storage/emulated/0/Download/magisk_patched-27000_RQmSG.img
And flash it: adb reboot bootloader, fastboot flash boot magisk_patched-27000_RQmSG.img

The root is optional and not necessary if you don't need it, but it's a great way how to install system wide adblocker, application firewall, etc.

Flashing GSI image

The GSI images were originally designed for development purposes and testing, but the community quickly adapted the GSI flashing process to modify the phones in the wild. There are may GSI images that can be used to replace the stock system - see the Generic System Images list.

I've started with the LineageOS from the Andy Yan's builds. There are several variants, I used one for the A/B partition scheme, vanilla (no google apps) and no superuser version - lineage-20.0-20240516-UNOFFICIAL-arm64_bvN.img. However the battery was draining like hell, the phone lost like 25 % over a single night. The crDroid in Android 13 variant was much better when it comes to battery life, but after flashing Android 14 variant, the battery drain was back. After several days of flash-let run for 10 hours and repeat I've finally settled down on the LineageOS 21 Light from Andy, the battery life is quite good and it works nicely.

The flashing is quite simple (don't forget to flash the same partition as you flashed with vbmeta):

fastboot flash systemlineage-21.0-20240518-UNOFFICIAL-gsi_arm64_vN (will flash to a currently selected slot)
Wipe all data (factory reset), can be done in the recovery menu
fastboot reboot

Post-install steps

I'm not very fond of google spying on everyone, therefore I don't install google apps and rather use alternatives, if you want google for some reason, see the opengapps. To make the android usable without google and to utilize the root access, I usually do:

Install Magisk for root access management
- Hide Magisk in settings - it will be renamed to a custom name
- Enable Zygisk to better hide the root from apps
- Add apps that should not see the root access
Install F-Droid - alternative open source apps store
Install microG to allow running apps requiring google services - opensource google framework reimplementation
- Add microG repository to F-Droid
- From F-Droid install microG Services, microG Companion and microG Services Framework Proxy
- (Optional) Install some location provider, I like the Local NLP Backend as it doesn't use online data but rather creates it's own database during life of the phone
- Open the microG app and make sure all items under Self Check in menu are checked
- Reboot phone
Install Aurora Store, an unofficial google play app, it can download apps from google without using a google account
Install AdAway (root required) to block adds everywhere (app, browser,...)
- don't forget to launch the app, enable root and
Install AfWall (root required) application firewall
Install Davx for contacts and calendar synchronization with a custom server

Conclusion

The phone with Andy Yan's build of LineageOS in Light version pretty well, it's my daily driver and so far, no crashes or other instabilities appeared.

Generic notes:

battery consumption of a clear ROM (no apps except battery monitor, no SIM inserted, WiFi on and connected) is around 0.9% per hour
battery consumption of a ROM with standard apps I use every day, two SIM cards, permanently enabled WiFi and bluetooth is below 2% per hour

What does not work:

face unlock
fingerprint scanner/unlock (it just crashes)
small back display
customizable side button
mobile internet only works with SIM card in slot 1, the SIM in slot 2 works for calling, but it's not getting an internet connection

Theory

I don't like a blind copy-paste approach when doing stuff, therefore I've done a small research and shared it here.

The android boot process is quite similar to other embedded linux base system:

1) Primary bootloader - stored in a Boot ROM of the SoC itself, written by a chip manufacturer. It does some basic device initialization and loads a second stage. It also usually verifies the secondary bootloader (integrity, authorization...). If something fails (corrupted secondary image) an emergency mode is entered - it's usally called EDL, BROM mode on MTK devices,... This mode can be used to reflash the device (if proper software is available). 2) Secondary bootloader - resides in storage external from the CPU (flash), it basically initializes TrustZone and loads a stage 3 bootloader 3) Stage 3 bootloader - finally something interesting, it's called Aboot (The android Bootloader), it implements the fastboot interface. The Aboot verifies authenticity of the boot and recovery partitions, decides which one to boot (from the buttons pressed during boot or from adb reboot target) and finally loads the RAM with the Linux kernel, device tree, and ramdisk from boot or recovery partition. 4) Linux/Android - The linux kernel finally executes, verifies the integrity of all the partitions being mounted and spawns the zygote process. The Zygote parent of all the android processes, it finally launches the Android itself.

Back before the android 8, all the necessary drivers and other software was stored in a single partition, each vendor had to create a complete Linux/Android system, include all the drivers, etc. Therefore any vendor ROM update or alternative ROM had to contain all the drivers, firmware blobs and other stuff, which made modding pretty hard and complex task. I

It also meant that creating an upgrade for your phone when a new security fix or android version appeared was a pretty complex and time consuming task, which was one of the reasons the cheap Chinese phones had to live their life with only very few or none updates after the initial release.

Then with Android O, the Project Treble appeared. The Project Treble came with a good idea - the vendor specified software got separated from the Android itself. So now, the Android OS could be replaced without touching the vendor specific software libraries.

In theory, any GSI (Generic System Image) of same or newer Android version (no backward compatibility of vendor libraries interface is required) could be flashed to a Project Treble compatible phone and it should just work(tm). After few years, the reality is still not there, the basic peripherals usually work under GSI, but the more exotic one (fingerprint sensor) still tend to have issues, also the power consumption can be inferior to the stock ROM, etc.

Partitions

There are (assuming a Project Treble compatible phones) two possible partition schemes, the older scheme with only a single system partition (old, A only,...) and a dual system partitions (called A/B). The A/B scheme was designed to allow seamless system updates. The old scheme required OTA process to boot into a special recovery partition to reflash the other partitions (requiring a loooooong reboot), during the process the phone could get bricked or something else could go wrong with no way to go back.

The new (A/B) scheme doubles the important partitions (system, vendor,...) into so called slots (slot A and slot B). During the OTA process, the system can be running normally from the current slot, while the other, unused, partition is being overwritten. Once it's done a simple and short reboot is enough needed to bring the phone to a newly flashed firmware. If one of the partitions gets corrupted, the phone simply boots the previous one.

Common partitions on both schemes:

bootloader - read only, actually not a full blown partition, it's located at the beginning of the flash and it gets loaded by the CPU during its boot process, it verifies validity of the other partitions (see Verified Boot), integrity of the boot and recovery, determines slot to boot for A/B schemes, decides if recovery shall be booted and finally loads the selected kernel and ramdisk into RAM and executes it.
recovery - read only - a complete linux filesystem, including kernel, for recovery purposes. On legacy scheme, the partition is used to rewrite other partitions during OTA update. On A/B scheme, it's not needed in theory, but is almost always present to simplify development, manufacturing, etc.
cache - read write - cache for few apps (special permission needed). OTA data downloaded here on legacy scheme.
userdata - read write - exactly what it name implies, the user data

A only:

vbmeta, vbmeta_system,... - see below, basically it contains a crypto signature for integrity and validity checking of other partitions
boot - read only - contains a Linux kernel and a basic ramdisk, it's loaded into memory, mounts other partitions and starts runtime places on the system partition
system - read only - system apps, libraries and stuff, just a good old plain linux filesystem, the GSI rom fits here.
vendor - read only - vendor specific code, not part of the Android opensource project - drivers and other stuff

A/B - the slot specific partitions (replace x by either a or b):

boot_x
system_x
vendor_x
vbmeta_x
vbmeta_system_x
...

There are much more stuff on the common android system, if interested, run ls -l /dev/block/platform/soc/11270000.ufshci/by-name/ on your phone. The path can be slightly different, based on your phone.

Bootloader unlocking

The bootloader of the android system checks integrity and validity of the data it's loading into the memory. Without getting manufacturer private key used for signing the stock rom files, it's impossible to run a custom software on your device. You would need to modify the bootloader itself or even somehow hack the keys storage on the SoC which could be close to impossible.

Fortunately, the bootloaders of many phones can be unlocked, it basically means some flag is set inside the bootloader to skip the verification. Sometimes all that's needed it's a simple fastboot command and a button press, sometimes you need to explicitly ask the vendor for unlocking key, install some insane chinese software, register, wait for month (looking at you, Xiaomi) to get the key,... And sometimes it's disabled completely, so unless you are a gifter hacker with months of free time, it's better to just sell the phone.

Once the bootloader is unlocked, it will report the orange state and halt for 5 seconds before booting. See the Boot Flow documentation for more details.

vbmeta

The android uses a linux feature DM-Verity to check for integrity of the data partitions (system and other read-only parts in the flash). It uses a cryptographic hash tree to do it - there's a hash stored for each 4K block of the storage, these hashes and hashed and so on until a single hash is obtained - the root hash. This way the android can e.g. detect when a malicious software modifies something in the system partition (insert a virus or something).

The hashed have to be stored somewhere, and that's when the vbmeta partitions come in play. This partition holds hashes for boot and other stuff. Additionally, the content of the vbmeta is cryptographically signed to allow any tampering with the data.

The vbmeta partitions can (and usually are) be chained, so usually there's a vbmeta_system partition with hashes for system partition, etc. Once you break any part of the chain (by changing one of the vbmeta partitions or the data which are protected by the dm-verify), the system won't boot.

To flash a custom rom, the vbmeta partition needs to be flashed with a modified content to disable the integrity checking. As the vbmeta contains a root of the chain of trust, only this partition needs to be written, the others (vbmeta_system) will be simply ignored as the root is gone.

It would be nice to flash a valid vbmeta content to allow integrity checking of your ROM, but as the vbmeta content is usually signed by the vendor, it's not easy to do it, therefore people usually tend to ignore it.

Fastboot

The fastboot is a little confusing term. It's

a protocol used to communicate between phone and computer in bootloader and recovery modes
a PC software that talks over a fastboot protocol with phone
android phone mode used to flash system and other dynamic partitions

When the phone boots into a bootloader, it will be accessible over the USB by fastboot application on computer. This mode is used to flash critical and static partitions of the flash memory - like recovery. The bootloader itself is really simple and doesn't necessarily support access to dynamic partitions (system_a for example).

A more advanced fastbootd mode is accessible in a dedicated fastboot mode, usually accessible from the recovery, by calling adb reboot fastboot or by a special combination of button presses during power on. The fastbootd is almost the same as the bootloader one, but in this case, it runs as an userspace app inside the recovery system and usually has much more capabilities - it can flash dynamic partitions. The same fastboot application on computer is used for communication.