[Android Q&A, Help & Troubleshooting] Tzul:
I just checked. Yes, most files are identical without the padding. Including the recoveries.

The filesystem partitions (system, cache, userdata) differ quite a bit, but I'm not surprised about that. File modification dates are probably different, and the same block of data can end up getting stored at different places in the partition. Which is why I doubt that "diskInfo" would be of any help, it that's an app that shows how much is used or empty space. Even if only 1 byte is used, it could be located at the very end of the partition...

About the stock recovery: both of us didn't actually back up the new S000121 one, but the older S000120 one. That's because those incremental updates work like this:

They update (=patch) the "boot" partition, but not the recovery partition. Instead, they create/update the following files:

/system/etc/recovery-resource.dat (a ZIP file, usually)

/system/recovery-from-boot.p

/system/etc/install-recovery.sh (or /system/bin/install-recovery.sh)

The install-recovery shell script gets executed on every boot. It checks the SHA1 hash of the currently installed recovery, and if it doesn't match (i.e. the recovery is not what it should be), then it uses the recovery-resource.dat and recovery-from-boot.p files to create and flash the recovery image.

I guess they don't do it this way to save a few MB of space in the update file, but rather to make sure that the recovery is always "valid" and always using the same kernel as the boot image.

Anyway, this mechanism is easily disabled, either delete/rename install-recovery.sh or recovery-from-boot.p. Custom recoveries usually do that, and SuperSU repurposes the install-recovery.sh script to launch itself.

For future updates, this means we should proceed as before to create a full readback before first boot, but then we should boot Android at least once, unmodified, so that the new recovery gets created, which we then have to read back separately.

I'm just uploading a revision of my A10-70F_S000121_151222_ROW file, with the proper stock recovery, and with TWRP instead of Carliv added as bonus, but it'll take a few hourse.

I've also updated TWRP, by the way (same link). Fixed a problem with exFAT not showing up in the Wipe menu, and added an "Install SuperSU" button to the Advanced menu for [MENTION=5658496]Sparkrite[/MENTION]. ;)

Exactly. The value might or might not be different on other hardware (flash memory is organized in pages, 2048 = 0x800 is a typical page size, but different chips could use different values, e.g. 4096), so always check the readback with a hex editor (a Mediatek preloader should start with "MMM").

No EOF marker, but there are often headers that specify the size. For the preloaders that I've seen, the size was specified at offset 0x20 = 32, e.g. "68 20 02 00" = 0x00022068 for the current one.

Well, you're supposed to save all your data in the cloud. The cloud never becomes corrupted. And the NSA will kindly make an additional backup of your data. ;)

(I'm totally agreeing with you on this, if it wasn't clear.)

Sorry to hear your first encounter with Xposed hasn't been great. Strange that it would affect the WiFi Signal Booster. I haven't tested that app yet, but I'm going to.

Thanks, I already know about those logs. The partition information there is simply the output of /proc/partinfo that I mentioned in my last post. The timestamps aren't accurate, of course. The tablet's clock was either not set yet or got reset somehow (happened to me a couple of times while installing my test builds of TWRP).

---------- Post added at 02:41 PM ---------- Previous post was at 02:34 PM ----------

Yes, it's very easy. Just install a custom recovery, as explained here.

Though you might want to use TWRP instead of the Carliv recovery mentioned in that guide. If you simply exit TWRP on an unrooted tablet, it will bring up the option to root it.