** = Edited on 03/31/2018
* = Edited on 03/25/2018
I have an application for which I'd like to transfer the app data from my physical device to an emulator on my PC. *The data consists of a single .sol file which is saved at:
I'm not proficient with ADB / Linux / Bash, so I'd appreciate any efforts spared to elaborate with more verbose guidance (I'm not afraid to read through essays, I'm afraid of the one-line answers). The device has to be kept stock (rootless). Here are the specs:
Samsung SM-N950U Stock (T-MO)
*Bootloader Version: N950USQS5CRL1
Emulator (Destination): Runtime Environment: 6.0.6 Good
Device Model: Samsung Galaxy Note 8 Android 5.1.1 (US)
After quite a bit of digging around, I finally got ADB backup to
work do something (after an OTA update, it kept producing a 1KB file with no error echoed back). I'm not 100% sure the backup is now fully functional, but it now produces a 17KB .ab file (I am using the -noapk argument, and the contents of the backup should decompress into a .sol file so it wouldn't be a huge file or anything). Here's the syntax I used:
adb -d backup com.example.example "-noapk -obb -shared" -f examplebackup.ab
When using ADB restore to the emulator, everything goes smoothly and no error message is produced (unlock dialogue prompt comes up so I know it's going to the correct device). However, opening the application it acts like I've just opened it for the first time, so no save data was transferred over. For reference, this is the syntax I used:
adb -s 127.0.0.1:21513 restore examplebackup.ab
I know there are several similar threads, but none addressed this type of cross platform transfer that I saw, and none of the potential workarounds or solutions seemed to work (although one of them did help me figure out the 1KB backup issue). Hoping to get some help with this, and my apologies if this was addressed somewhere but I just couldn't understand it.
Thanks in advance for any assistance!
While testing ADB backup on other applications (thank you @Robert for the helpful suggestion), I managed to figure out that ADB backup was working the entire time -- it was ADB restore that wasn't working. So the 17KB .sol output was the correct one (it's obfuscated when directly opened so I couldn't tell the difference directly). So, lesson learned: if the manifest includes the backup flag as "enabled", then ADB backup should work regardless of root; and if the output .ab/.adb file is >1KB with -noapk, it's a good sign that it was successful.
Now, I just need to switch gears and figure out what's going on with ADB restore. Any ideas on this? I'm no longer in a precarious situation since I at least know the backup part is working and I can manually transfer the .sol file as needed, but it'd still be great if I can use ADB (via .bat) for the process.
In the past weeks, I've pieced together more information from here and there, and I've decided to come back and update this post for any others who might be struggling with the same issue. At this time, I believe it will not be possible to accomplish my objective of retrieving my data, but it's not necessarily true for others. Below, I'll explain my attempts and the setbacks I encountered from a layman's perspective, but if anyone more knowledgeable on the subject feels inclined to clarify anything I'm unaware of or misunderstood, it'd be greatly appreciated.
I have spoken with technicians at Google, Samsung, the mobile carrier, the community members from all of the above, and obviously here on Android Stack Exchange (with zero answers). All of the "official" sources where I was able to get a response from have told me it isn't possible, and unexpectedly proceeded to push the blame onto the developer and/or each other.These "tech support" reps were all completely clueless, unbelievable.
- From my understanding, in order for the ADB backup method to fully function as I want it to, I would either need root access,
orthe application needs to be debuggable. I have checked the app manifest and have seen that it isn't (but backup is enabled, by the way). **For the record, this flag being enabled means ADB backup will work regardless of root; I incorrectly interpreted this as whether it allows the "official" backup methods -- such as the device OEM's backup through the device menu -- to backup the app data.
- Another method through ADB I had read was to invoke run-as, essentially "borrowing" the application's identity and therefore inheriting its own permissions, and then pulling the data thereafter. Unfortunately, it seems this command has either been deprecated or broken since Marshmallow 6.0+ (I'm not sure if that's universal to the OS or just Samsung, either way it doesn't help my situation).
- I also wasn't sure whether a rootless BusyBox installation would make it possible to at least grant me access permissions to read the .sol file, if not copy the contents. I wasn't able to completely comprehend the XDA thread contents, but from what I could discern from the comments it still wouldn't have the required permissions to access \data\data.. (there seems to be some mention of a potential workaround by installing BusyBox into the same directory(?) but there wasn't any further explicit guidance or example that I could find).
- I believe the device-to-device backup methods (such as Google Backup or Samsung Smart Switch) might possibly work, since they should have the proper permissions(?); however, as I can only restore onto a device with same or higher OS version among other factors, I have no way of verifying whether or not it works other than by deleting my local data and trying to restore it (obviously, I'd be shooting myself in the foot if it didn't actually work).
- As the Google Backup method states it needs to be restored onto a device of equivalent OS version or higher, one option I had thought of was restoring onto an emulator running Oreo 8.0, and from there enabling root to extract the data I needed. However, the only one I could find was the default provided through AVD from the Android SDK; an 8.0 emulator was available with Play services enabled and preloaded, but for whatever reason it shows the application is incompatible, so that was a dead-end.
- Smart Switch does offer a backup "to external storage" option, but even though I have encryption disabled on both my device as well as the Smart Switch backup settings the backup still results in an .enc container, which I've not been able to find a way to decompress or extract from (see below for further on this).
- Unfortunately, I was stupid enough to install the latest OTA update before checking, but there doesn't seem to be a method for root at this time on the newer bootloader/firmware versions. So for the time being, I'm just stuck with no way to retrieve my own data.
Things I'd still like to find out:
I am inferring that invoking adb backup with the correct syntax and -noapk argument outputs a non-zero / -single kb file because it is properly backing up all the application-related data except what's stored in \data\data.. ?Or is the inclusion of the enabled backup flag in manifest supposed to make ADB backup work regardless of root? If the latter is true, what am I doing wrong? **Latter was true, it was just ADB restore that wasn't working correctly. I'm wondering if I can somehow create a virtual "external storage" in an emulator and use Smart Switch to restore the .enc file; the emulator I use does offer shared storage between VM and desktop, but they are not recognized in Smart Switch as mounted "external storage", therefore leaving no way to point to the file).Otherwise, it'd be great to be able to directly access the .enc container somehow, I just don't understand the point of letting the user choose unencrypted if it's going to be encrypted anyway. **Still want an answer to this, as unlikely as it is for me to get one. Although I have a (likely biased) feeling it shouldn't have to come to this, I do have the means to contact the app's developer. If I do go that route, what would be the more appropriate "means" to ask for in order to achieve the desired result? E.g., "can you please make your app debuggable?" vs "can you change the directory for this particular file to save in a non-system directory?", etc.**Embarrassingly enough, I did end up reaching out to the dev, only to figure out it works a few days later. I'm curious if there's anything I can do via SetEdit (after elevating permissions as instructed) that might help me with this problem?
- **Figure out what's going wrong with ADB restore.