[Android General] Tzul:
It's not really weird, in my opinion. It could be better documented, but these tools rarely are. Anyway, once you've grasped the basics (scatter file, Download, Readback), it's easy, and you shouldn't try to do other things with the SPFT anyway.

That's not quite correct. Here's how it works in detail:

When Android boots, the script /system/bin/install-recovery.sh gets executed at one point (used to be /system/etc/install-recovery.sh in older versions).

The default content of this script does the following:

Check if the current recovery partition matches the expected checksum.

If not, then use the "applypatch" command to flash the recovery partition with a new image, built on-the-fly from three components:

The current boot partition. Both boot and recovery have an individual copy of the Linux kernel, which is the biggest chunk of data in both files, so it makes sense to take the boot image and tweak a few things in order to "convert" it to the stock recovery.

A patch file, /system/recovery-from-boot.p, which will fix the main differences between boot and recovery.

A "bonus file", /system/etc/recovery-resource.dat, basically a zip file containing some data that would be inefficient to store in the patch file. Mostly png graphics used by the recovery.

The script checks the SHA1 checksums of both input and output (boot partition and the constructed recovery image). If there's a mismatch, or if any of the required files are missing, then the recovery cannot and will not be changed.

Now, if you install SuperSU for root, it "hijacks" the install-recovery.sh script file to launch its own daemon (background service). SuperSU saves a copy of the original script as "install-recovery_original.sh", but does not run it. So, having SuperSU installed means no automatic overwrite of the recovery.

Even if you don't have SuperSU installed, every time you leave TWRP, it renders the install-recovery.sh script ineffective. It does so by renaming the patch file /system/recovery-from-boot.p to recovery-from-boot.bak! A simple solution that does not clash with SuperSU's handling of install-recovery.sh.

Very interesting, thanks for the info!

I've actually used the new bootloader with Android 4.4 on my A10-70F for a while, and it appeared to work without issues!

By the way, you keep calling it uboot...

uboot = Das U-Boot (universal bootloader)

lk = (L)ittle (K)ernel

They're both bootloaders, but they are different ones. Some devices use uboot (I once had one myself), but others like this tablet use LK.

Yes, I know, I haven't seen any OTA update for the A10-70F or A10-70L that does include lk.bin.

And according to some users on the German forum, even if your tablet comes with Android 5.0.1 preinstalled, that's no guarantee that is has the new bootloader. We noticed because "fastboot flash recovery" didn't work and because /proc/cpuinfo showed the wrong info.

Interesting, I didn't expect that. This is different for the A10-70F. By default, it shows "Hardware: MT6752", because that's written in the device tree attached to the end of the kernel (even for the A10-70L, you can open boot.img in a hex editor and search for "MT6752").

I reverse-engineered the new bootloader for the A10-70F a bit, and found out that it patches this value in the device tree, after detecting which MediaTek chip is actually installed. This will result in "Hardware: MT8165" being displayed in /proc/cpuinfo. The old bootloader doesn't do this. Maybe the A10-70L version does, or maybe the value gets updated/corrected in another place...

Thanks again, I'll take a look at the file when I have more time! :)

By the way, in case you haven't seen, I've patched the old lk.bin so that it can do "fastboot flash recovery", but of course I haven't tested the A10-70L version yet (lk.patched.bin).