Messages Import Export issue

Checklist

• I can reproduce the bug with the latest version given here.
• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected app version

1.0.1

Affected Android/Custom ROM version

Android 8.1

Affected device model

Moto G5 Plus

How did you install the app?

GitHub releases

Steps to reproduce the bug

1. Open app, go to settings and click on export messages.
2. It asks for file name without .json
3. Android system may ask you to complete task with native android files or any other file manager installed on device (in my case fossify file manager).
4. Choose location for exporting.
5. Now try to import same that just exported.

Expected behavior

It should be imported without any issues and restore all the SMS and MMS.

Actual behavior

While trying to import same file, it always prompt native android files and the exported file stays greyed out and not able to select it. It also doesn't contain any extensions by default (especially if exported via fossify file manager). But adding extension .json manually doesn't help much either. In my observations, if file is exported via native android files, added .json when android files asks for name and exporting it to "Downloads" directory only works. Even if I export it to any other location other than downloads, it still stays greyed out.

Screenshots/Screen recordings

No response

Additional information

It could be fossify file manager bug as I tried to export back-up from Notally, extension was always missing. Also similar bug is reported as (FossifyOrg/Notes#13). But it doesn't explain why this works in only Download folder and not to any other location.

[biopsin]

Duplicate of #6

[Aga-C]

@biopsin From the descriptions, these two are completely different. Here the file is exported, but without extension, so it can't be imported.

Duplicate of #6

There's no crash or any visible error in this case, export is always successful (with or without extension). And even with proper extension, the same file can not be imported unless it is exported to "Downloads" folder in home directory, and if its unmoved, untouched. If I move same file to another location and try to import it, it is greyed out. If i again move it to Downloads and try to import it, it still stays greyed out. So, both issues are very different ones in my opinion.

[biopsin]

But what sizes is the exported file?

But what sizes is the exported file?

The file which gets exported is usually of few MBs (around 5 MB), I had 2-3 years of SMS which i was backing up.

[tom93]

There are two separate issues:

1. Missing .json extension on export. As you wrote, very similar to FossifyOrg/Notes#13. I'll open a PR. (Update: #136)

2. Android reports the MIME type as "application/octet-stream" for .json files outside the Download folder. I can reproduce this on Android 9. In particular, if I export to the Download folder (even without the .json extension) then the MIME type is reported as "application/json" (using "Get info" in the native Files app), and if I move this file outside the Download folder (e.g. into Pictures) then the MIME type is reported as "application/octet-stream". I'm not sure why that is (I suspect the Download folder stores additional metadata, but I can't find any reference). Update: Yes. The Content URI is of the form content://com.android.providers.downloads.documents/... rather than content://com.android.externalstorage.documents/... which shows that the provider is DownloadProvider.
   As a workaround, how about adding "application/octet-stream" to the list of allowed file types? (Update: Implemented in #137)