[Galaxy S II Original Android Development] bruzzy:
Hi lyriquidperfection,

thanks for providing this tool!

I've been testing it with SM-P900 for some time now (so far only the backup functionality) and would like to share my experience. I also sent you a "feature request" via PM a while ago (at that time I wasn't able to post on this thread), but unfortunately didn't get a respond on that yet... I hope, the following helps in any way. Please, don't get me wrong! I'm not criticising, but trying to give some constructive feedback and help to improve the tool.

The main testing I've done with v2.1.61, but I also had a quick check with v2.1.73 which showed the same results.

Device recognition in recovery

When starting the tool while the device is booted in recovery, EFSPro doesn't recognize the device as beeng online.

I guess, in order to test whether the device is online, EFSPro checks the respond on the command adb devices. As far as I can see, the device status is shown as "online" when the device is booted in normal mode, but it's shown as "recovery" when booted in recovery.

So if my assumption for the way EFSPro checks the device's status is true, this issue shall be fixed, when EFSPro also counts "recovery" as a valid "device is online" status.

Command execution in recovery

In order to get EFSPro also working in recovery, I followed your proposal in an earlier post. So the workaround was: have the device booted in normal mode, start EFSPro, let it chack the device connection, then reboot the device in recovery (notice: this workaround will only work, if your device is able to boot into normal mode - which might not be the case, when something is screwed up and you want to restore).

So having the device in recovery, I tried to do a backup. Here I got an error message that the command couldn't be executed. The reason for that was that the su binary was not in /sbin. In my case (I'm using TWRP), there is an su binary in /supersu and if I mount /system, there is also one in /system/xbin. My workaround was to copy one of those to /sbin. This worked fine, but it's only temporary, since /sbin is only a temporary location, which gets overwritten on next reboot.

My approach for a proper solution would be (in EFSPro code):

check, whether the device is in recovery

if so, check whether it's already in su mode (in that case you don't need to start with "su")

consider above findings on each following command

Verification of data consistency

As far as I could follow the steps, EFSPro is doing following on starting a backup (please correct me if I'm wrong):

dump partition part_name to part_name.img

get md5 checksum of partition part_name

get md5 checksum of part_name.img

check whether the two checksums match and continue if so, abort otherwise

iterate 1-4 for each partition to be backed up

make a tar.gz archive including all the partition dumps

clean up (delete all the partition dumps)

copy the tar.gz archive to PC (steps 7 and 8 may be switched, but it doesn't matter)

finished -> notification: "Backup completed successfully!"

Relying on that procedure, there is a risk on having a broken backup file, because of a missing verification at the end of the procedure. I.e. even a checksum match was accomplished successfully at step 4, there was a further processing of the data in step 6. And to be correct, the file on which the checksum match was based isn't even kept in the original form.

What I'm trying to say is: to have a trustable confirmation that a backup is valid, the final tar.gz archive has actually to be extracted and a checksum match needs to be performed on the extracted file(s). Only after that test you can finally rely on the data of the tar.gz...

Why I'm spendig so many lines on that? It's not only a theoretical thesis. I experienced exactly this behaviour, as I tried to make a backup of the partition userdata to the external SD-Card. The size of this partition is about 26.5 GB, but there is only about 300MB of space used. My first try was with a 32GB SD-Card. The backup was successfully finished (I got the popup "Backup completed successfully!"). When afterwards tryed to unzip and untar the archive I realized that the file was broken (unexpected end of file). First I thought, my SD-Card was too small, so I tried it with a 64GB one - same result. Then I tried something different: I interrupted the connection to the device just after step 4 and created the tar.gz archive manually (tar czf ../SM-P900_<date>_<time>.tar.gz userdata.img) and got a file of 305 MB. To make sure, this one isn't broken as well, I extracted the userdata.img file, got the md5 checksum from that file and it was exactly the same as the one of the partition. So this worked.

I still don't know, what goes wrong with step 6 of the EFSPro baclukp procedure (it only goes wrong with that one "big" partition), but an additional verification of the md5 checksum after step 6 or even after step 8 would prvent EFSPro on confirming a valid backup even if it's not.

Please let me know if it's of any help for you or if you have any further questions or you want me to test something else.

Cheers,

bruzzy