I face nearly the same issue, except the two alarm times in the clock widget (they were magically remembered by the phone).
I also didn’t encrypt my storage, but when going to “factory reset mode” I couldn’t even mount anything (my computer didn’t get any input) or write to the memory for it was/is write-protected.
On top of that, fasboot didn’t help me either (or any similar software from code.fairphone.com).
–
If you run GNU/Linux (and know how to use it ), there’s PhotoRec and Testdisk (in the same package); I also found a series of packages “forensics-*”; the description sounds promising, but I don’t know them (yet).
The crux now for me is getting at least as many rights for my phone with USB as for an USB drive, when I plug my phone in my computer.
You could do an adb pull of the relevant block device (I don’t have a FP2 to check which one it is, sorry). You can then work on the image using recovery tools. I don’t recall coming across a way to get block-level access directly over USB. For anyone else reading this - recovery of lost data in this manner only has a chance if the storage was not encrypted. In the case of the 18.10 update bug that affects devices encrypted under Android 5, data is recoverable as long as you did not proceed with the wipe suggested by Android.
How do I do this? I’ve installed the package adb, but $ adb pull requires an argument and taking the device found from $ adb devices, I get
adb: error: remote object ‘b0f697’ does not exist
# adb connect b0f697
unable to connect to b0f697:5555: Name or service not known
The documentation seems to be clear, but I couldn’t make it to connect with CLI to my FP. Did I just miss a command? How to make an image of the FP then?
You need specify a file, or something that can behave like a file - in this case the block device - that you want to pull from the phone. As said, I do not know the correct name for the block device on the FP2.
Good guesses can include /dev/block/mmcblk0 for the entire storage (all partitions). This stackexchange answer lists some commands that may or may not still be functional in newer android versions. Using those, you can figure out where the userdata partition is exactly. If you’re lucky, /dev/block/platform/msm_sdcc.1/by-name/userdata will get the userdata partition without having to search. A shell can be started on the phone from the computer over adb using adb shell, but remember to exit or quit to close the connection before trying adb pull again (as that needs to run on the computer, not the phone)
@Johannes I could copy the files and dirs with $ adb pull mnt, but I didn’t get a copy (*.img or something) of the disk/storage, where my deleted files (hopefully) still are written onto.
A copy of the block device (under /dev/block/) is the same as a dd image. I seem to recall a pull of the block device should work (at least when in TWRP recovery), but if you can’t get at the block devices, directly with adb pull, you could make a dd copy of it (via shell, as root) to a file on the sd card. If that works, you can either pull it from there or use the card to transfer it.
Also: If you have an SD-card formatted as internal memory, this becomes very tricky, as you’ll likely want to have the image of the combined storage space, so you cannot write to SD card or internal storage.
), there’s PhotoRec and Testdisk (in the same package); I also found a series of packages “forensics-*”; the description sounds promising, but I don’t know them (yet).