duplicate of #749

I second this. There is no upvote on issue, only thing I can do is leave a "me too" comment.

Big plus if it can read and import from contacts.db and mmsms.db that was recovered from a nandroid backup.

Since this feature is primordial to me, and with the lack of response, I made my own app. It only dumps for now but it may be enough for some people like me: Epistolaire. App on F-Droid, and github repository

@hydrargyrum well done, thankyou.
As you may have gathered, the future for this app lies in integration with email.
Relatively few users actually care about keeping messages in the SMS app on their phone, when it's so much easier to see SMSes in the context of other communications including gmail & hangouts.

Do you think it would be useful to share a common library?

@kurahaupo,

As you may have gathered, the future for this app lies in integration with email.
Relatively few users actually care about keeping messages in the SMS app on their phone, when it's so much easier to see SMSes in the context of other communications including gmail & hangouts.

The backup can be transferred to a workstation. In the Epistolaire repository, you'll find a Python converter script that converts SMSes and MMSes to Maildir, which you can easily use to push to an SMTP server.

Do you think it would be useful to share a common library?

Of course! I'm quite new to android programming so I'm not sure how to make a shared library.

The heavy lifting work is done in https://github.com/hydrargyrum/epistolaire/blob/master/app/src/main/java/re/indigo/epistolaire/MmsDumper.kt Functions return org.json.JSONObject instances rather than custom classes, but any code can extract data from org.json.JSONObject values.

How do you see it? (Anyway, I published in public domain so you can do whatever you want)

Thanks for that. I will keep an eye on this subject.

It occurs to me that installing an IMAP server on ones phone would solve a number of problems all at once.

In closed ticket #979 @pintspin wrote:

I have already done that , here is the app , ( simply read all SMS and write it on a text file ) in external memory at the moment but functionality for internal is also there

published app Link here
https://www.amazon.com/dp/B0891VGDXJ/ref=cm_sw_r_tw_dp_U_x_TBiZEb3AKC72G

Source code here
https://github.com/pintspin/ReadSMSpublic

Dont know if that is of any help , i was having trouble so i just created this very primitive app to save my text message in a text format and to sent it as attachment to gmail or email ( still working on this ) Google rejected my app because of dangerous permission so i decided to publish the app on amazon and it worked like charm ...

Please read the substantive technical discussion and rationale in #749 before commenting here.

In particular @jberkel wrote there:

I'd prefer (esp. for privacy reasons) not to store a copy of the user's data locally.
...
it's a question of responsibility: if they are stored on Gmail I'm not responsible for privacy issues (Google is), but storing locally is a different thing (cf. the privacy policy)

I think all arguments pale given the naming of the app. It's SMS Backup, I wanted to backup my text messages to a local file. I can't, so not adding this fails to fulfill the basic promise of the app and I ended up here via googling where the button was, as well as uninstalling the app again. If this is not what it was meant to do, maybe it should be renamed to "SMS IMAP Sync" to stop misleading users, otherwise I recommend adding this feature.

Regarding the privacy policy:

but storing locally is a different thing (cf. the privacy policy)

This really is a non-issue if it is by user request. Just write into the privacy policy the app won't ever store data locally unless the user asks to store it locally, in which case it is up to the user to delete or take care of it. It's not that hard. (disclaimer: I'm not a lawyer)

@ell1e FYI having "Backup" in the name has been an obstacle to using XOAuth to access Gmail, because that means that the review team at Google classified the app as "not a program whose principal purpose is to allow the user to send and receive email". There's a moderate chance that they will relent if it is renamed and marketed as a plugin to any standard email program.

One possible future for this project is forking into multiple cooperating apps: one which manages the interaction with Gmail, with its permissions tuned so that it can pass Google's requirements for "sensitive scope" access (and thus restore XOAuth access), and at least one other that manages non-email functions. (There is precedent for this approach: projects such as OpenIntents have suites of cooperating apps where each has only the minimal permissions it needs to perform its own job.)

A "local file" plugin would certainly be possible then.

In the meantime, I recommend you look at
@pintspin's ReadSMS project

NB: I'm only a minor contributor; it's up to the principal developer @jberkel to say for sure.

@ell1e some further thoughts:

I agree that it seems odd to say that saving to a local file violates the privacy policy when that would only be done at the explicit request of the user. However the current privacy policy is unequivocal on this point, so the first step would need to be an amendment to the privacy policy, and amendments must always be notified to users when they upgrade from an older version, regardless of how trivial the modification is. That notification itself requires coding effort, even if it's just to add a note to the new configuration section pointing out that the privacy policy has changed.

I would argue that an app that only wrote to a local file and called itself "SMS Backup+" would be more misleading to a naïve user, since the most common way that people lose access to their SMSes is by losing or destroying their device. And I am not sympathetic to arguments against "using the cloud" per se, since it is straightforward to configure SMS Backup+ to use one's own IMAP server.

That said, having more ways of connecting to external services and devices would be better, and a modular approach would assist with that.

Some related features that have been requested:

• save messages to local files:
  • all messages into one file
  • one message per file
  • into files based on date, thread, or correspondent
• and saving as:
  • RFC-822 (current)
  • JSON
  • XML
• forward to outgoing email
  However I note that:
  1. SMTP is unreliable and unverifiable, so it would be a poor "backup"; and
  2. the envelope cannot match the actual message, so it would fail (probably invisibly) when using a DMARC signed domain.
  3. on the plus side, the RFC-822 format is exactly that used by IMAP, so some code could be reused.

For me this is also a must have function. And unfortunately there is no proper solution for this atm.

With proper I mean, foss, with functions to export / import, schedule, destination folder, encrypt export, without need of google services.

I would pay for an app like this.

@rubensudos see the local-save solution by @pintspin mentioned above (and in closed ticket #979).

@rubensudos see the local-save solution by @pintspin mentioned above (and in closed ticket #979).

Thanks for the fast reply.
I just can't believe that there's no decent option to backup an android device without using big tech spyware and trade my data for a free service to be able to do a simple backup. Something as simple and fundamental as that, not possible.

self-advertising: @rubensudos https://f-droid.org/packages/re.indigo.epistolaire/ backups sms and mms locally and is open-source

self-advertising: @rubensudos https://f-droid.org/packages/re.indigo.epistolaire/ backups sms and mms locally and is open-source

Thanks for the info and thanks for the awesome work.
But unfortunately is not something I could use because when I make backups is to be able to restore the previous state of the device in case something happens to it and I believe this app doesnt have an option to restore SMS, etc back to the device or does it?

If anything cares to implement an IMAP server that runs inside the phone (and obviously, only listens on localhost), SMS Backup+ could use that to both save and restore state.

Obviously that makes the restoration process a bit more cumbersome, but it work "just work".

Agreed. Why bother with gmail accounts if you can simply drop a file in internal storage? Doesn't even require a Google account or Internet connection!

This really is a non-issue if it is by user request. Just write into the privacy policy the app won't ever store data locally unless the user asks to store it locally, in which case it is up to the user to delete or take care of it. It's not that hard.

And if it really were an issue, another possibility is letting the user store it in an encrypted ZIP file.