[Android Q&A, Help & Troubleshooting] Tzul:
MtkDroidTools is/was a handy piece of software, but it basically just automates a few things which you could also do manually without too much work. It uses ADB (the Android Debug Bridge) to communicate with the device via USB, to send Linux shell commands, read and write files, etc. To build a scatter file, it just reads the (virtual) file /proc/dumchar_info and transforms its information to the format used by the SPFT. Like [MENTION=2895182]clsA[/MENTION] said, the "proper" way of getting Scatter.txt would be with an official firmware release.

Mediatek has gone through a couple of different Scatter versions now. The first one is a Scatter file in its simplest form: just a name and a start address. Since there aren't any gaps in the partitioning, you can infer the sizes by subtracting adjacent start addresses. You can still see that in action if you open one of Lenovo's incremental update zips, they contain a "bare" scatter.txt like that. But that's enough information already to write a Scatter.txt version "1.1.1" or "1.1.2" as expected by the SPFT.

So, MtkDroidTools expects /proc/dumchar_info, but that doesn't exist anymore on our tablets, probably because Mediatek transitioned from their old MBR+EBR1+EBR2 scheme (master and extended boot records that point to the major partitions) to a new GPT scheme (you might have seen "pgpt" and "sgpt" - primary and secondary GPT). But there's still /proc/emmc and also /proc/partinfo, which also tell you all about the partition layout (the numbers in /proc/emmc are in sectors, i.e. have to be multiplied by 512 = 0x200). Here's some more info (mainly on the older MBR scheme), including sample output of /proc/dumchar_info at the very bottom, and even more info here.

It's MT8165. Yes the Scatter file says "platform: MT6752", and you can find references to it even in some other files, like Android's /system/build.prop (ro.board.platform=mt6752). That's not so much misidentification as "laziness": Mediatek's tools like the SPFT would have to be updated for every new chip number that they throw on the market, but this way they can bunch related chips together under one "platform" number. The MT8165 and MT6752 must be quite similar architecturally, perhaps the MT8165 is just a slightly modernized (cheaper) quad-core version of the octa-core MT6752. The product/project name of our chip appears to be huaqin (hq) 8752. Yet another number...

Significant differences? There might be some between different devices, but there aren't between different ROMs/firmwares of the same device, usually. As explained above, the addresses and sizes are the main thing, all the other stuff is just hints/metadata for the SPFT. Start addresses and sizes can change for the same device from one ROM to the next. Happened for example to my phone when it received an update from Android 4.2 to 4.4, which resized and shifted several partitions. In such rare cases, the "Firmware upgrade" flashing mode is required, because it will update the device's partition tables to match the new values. Otherwise the SPFT would complain about a mismatch between the partition tables and the values from the Scatter.

Only if you dump the entire memory region to a single file as I do, like clsA explained. If you dump each partition to an individual file, you get partition images instead of a disk image.

As explained above: Yes, it describes the device dependent partition arrangement, and the SPFT should verify that it matches the actual partition table on the device. No, it's not immutable, you can change it and make the SPFT update the partition table on the device accordingly, via the "Firmware upgrade" mode, but you shouldn't play around with that. ;)

The preloader is a special case, it gets a 2KB header while flashing, which you have to remove again after a readback in order to restore the original file.

Sounds good, I might give it a try, though being close to my WLAN router most of the time, my signal's strong enough.

It's not really like .NET and it doesn't replace the Google/Android framework. It exposes (hence the name) parts of the Android framework that apps otherwise wouldn't have any access to. Take the quicksetting tiles, for example. Many people would like to rearrange them, remove ones they don't need, and add other ones. Android doesn't have an API for that, thus there's not "an app for that" which enables you to do it. Some Android derivatives like CyanogenMod have built-in support for it (in their Settings app), but that's of no use to the majority of Android users for whose devices there are no custom ROMs. Xposed to the rescue. It allows Xposed-aware apps (called modules) to do all sorts of new things. GravityBox is big module that offers a lot of customizations, including handling the quicksetting tiles. It doesn't always work perfectly - depends on how much the manufacturer customized/fiddled with the standard Android framework. GravityBox knows nothing about our tablet's "Dolby" tile, for example, and therefore can't move or remove it. But for the most part it works fine (Lenovo luckily didn't customize their Android much, 5 even less so than 4.4).

You're welcome! Yes, some camera apps have a storage selection setting. But Mediatek-based devices usually have that "default write disk" option in Settings -> Storage. On older platforms like my phone, it actually swaps the mount points of the sdcard and the internal storage, making /sdcard point to the actual SD card instead of the internal storage, therefore affecting all apps. But sadly it doesn't work like this on the A10-70.

As for your question, that's a big one... not going to try and answer it. Just this: I think the restriction of the use of SD cards in Android has less to do with security risks and more with wanting to get rid of SD cards entirely, so that manufacturers can sell devices with a bit more internal storage for a ridiculous premium, just like Apple does.

I think the problem/error that clsA had was due to the 2KB header in front of the read-back preloader, not due to the padding. The padding really is unimportant, I strip it from the files where possible to reduce size.

The preloader file is part of SPFT firmware packages. When I noticed that my tablet came preinstalled with a newer version, I included it, of course. Yes, I compared it to the older preloader and figured out how to determine it's actual size. It's not that risky if you know what you're doing, and I've been looking at hexdumps and reverse-engineering file formats for more years now than I'd like to admit. ;)

That's the idea, and also the reason why the two "reserved" partitions that follow "userdata" have their starting address encoded as a weird negative number (0xFF... in hexadecimal) - their actual address differs between the 16 and 32 GB models, but this way, you can use the same Scatter and updates for both capacities.

I flashed my S000120 backup, copied the S000121 update to the SD card, booted into the stock recovery, applied the update, powered down the tablet, read back the data. And like I said, I always trim the files if possible.

I don't know how to determine the size of the ext4 fileystem partitions (protect1&2, system, cache, userdata). But I know how to calculate the sizes of boot and recovery, and some of the other partitions have a Mediatek header that directly tells the size, e.g. logo.bin. First 4 bytes are the Mediatek ID (88 16 88 58), second 4 bytes are the size in little-endian (68 E6 10 00 = 0x0010E668 = 1107560), excluding the size of the Mediatek header (512 bytes). Therefore, this logo.bin file would be 1107560 + 512 = 1108072 bytes. My readback splitter does this automatically, I should add Scatter.txt loading support and release it...

Thanks a lot for your donation, by the way! :)

---------- Post added at 06:40 PM ---------- Previous post was at 06:13 PM ----------

It's not in the menus. It works like this by default: when you exit TWRP via the Reboot menu, it checks if your system is already rooted. If it isn't, then it asks you whether or not you want to install SuperSU (note that the option "Only mount system read-only" in the Mount menu must be disabled for this prompt to appear).

I guess I could add an "Install SuperSU" button to the Advanced menu, there's room for one more. But that would only affect the default theme, obviously.

I'm going to try that, thanks for the idea!

Rashr requires you to be rooted already. But it should work just as fine and be just as safe as any other established way of flashing recovery images.

You don't need to edit a scatter file, just load a correct one in SPFT - I guess I should have included it. In SPFT, select "Download Only" mode, uncheck all partitions (you can use the button in the blue table header), then, in the "recovery" row, click on the "location" column to load the image to be flashed (the checkbox for recovery should automatically be ticked then). Power down the tablet, connect it via USB, and flashing should start (unless you don't have the VCOM drivers installed).