-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash trying to import #12
Comments
Hi, The problem described in #11 that I fixed should arise only when the Android version of the system from which the messages were exported is different from the version of the system to which they are being imported. Are all your systems Android 11? And yes, a logcat would be very helpful. |
No, in fact. Probably best to explain what I'm trying to do. What I was trying to do with your app is then to copy both mmssms.db backups, in turn, to the new A11 and use your app to export them to .json. This worked, as A11 seems to be able to parse different schemas. So now I have the two .json to match each database. I then removed A11's mmssms.db so it would recreate a new one at boot, which it did, and then tried to use your app to import both .json. This is where it failed.
Ok so, here's the relevant logcat on importing the .json of the oldest db:
And from the other:
I've replaced private data with 'xxx' Further info that may be helpful: mmssms.db-1 (A6 or A7):
mmssms.db-2 (A8):
mmssms.db-new (A11):
If you could upload the new apk with the fix, I'd appreciate it :) |
Just to add another test I've done, I've edited the .json files and removed fields not present in A11's db schema -- essentially 3 fields, "phone_id", "priority" and "pri" -- so the app doesn't crash on import. The thing is, since I can't find any documentation on the db schema and its changelog, I don't know the relevance of the data on those fields, so this isn't a proper migration. I wonder what's the proper way to do it... |
Yes, it looks like you're seeing the problem I just fixed. I, too, could not easily find documentation of the evolution of the database schemas, so my solution was to modify the import code to look up the list of columns in the local versions of the databases, and then to just drop all fields in the JSON that aren't present in those local versions. A fixed version for testing is available here. Update: I realize that my fix is just a programmatic way of doing what you did manually, and that a more sophisticated solution would entail actually figuring out what to do with the values in those fields. That would take a lot of detective and coding work, however, especially in light of the aforementioned lack of clear documentation of the evolution of the database structure, so at least for now we're just going to have to assume that those fields aren't critical and ignore them. |
Duplicate of #11 |
Yeah, guess so :( Oh just one more thing which may be of interest to you. Since I was working on backups of the .db alone, I didn't have the mms files (dir app_parts if I'm not mistaken?). This is fine for me, since I don't care about them. However, when using your app to export to json with the mms bits included, it crashes because the parts are missing and leaves the json file half done. Also, when importing an invalid json such as that one, the app will crash too when it gets to the invalid objects.
Thanks! |
Note that the current situation does not seem to be too bad: the fields in which I would assume people are most interested, such as addresses / phone numbers, dates, and message body / text and data parts, have been fairly stable - the current ones were mostly introduced in API 19 (Android 4.4, released in 2013). The fields that have been removed seem to be less interesting / important. If we ever encounter fields that are important to preserve, we can always add code to do some sort of migration.
Yes, the app is designed to run in a coherent / consistent Android environment, and will crash if the parts database is not present (the app does not look in the parts directory directly - it queries the appropriate Content Provider to get the parts). Note that working directly with the databases themselves is the goal of SMS Import / Export's sibling project, sms-db. That program runs on linux systems (and perhaps in other Perl environments?), and extracts messages from Android databases (of various sorts) into its own standardized database format, from which they can then be exported, currently only as XML. It's supposed to have SMS Import / Export-compatible JSON export capability as well, but I wrote sms-db before writing sms-ie, and I haven't gotten around to implementing JSON export yet. I really should do it, though - it shouldn't be too difficult.
Yes - sms-ie as written is rather fragile - it does little error checking / exception handling, and will crash if things are not as it expects. It would be nice to improve its robustness, but this has not been a priority heretofore :/ |
Hey there,
Have been trying out the app to export a couple of databases and to merge them by importing back, but when pushing the "Import" button, choosing any previously exported json, the app crashes instantly.
I'm on Android 11 (LineageOS) and have given permissions for both SMS and contacts, and set the app as the default for messaging. The mmssms.db is empty and the OS is freshly installed.
Thanks!
Edit: Just realised there was an issue (#11 closed) already here. Maybe it's the same thing? I'll do a logcat and get back to you.
The text was updated successfully, but these errors were encountered: