I wanted to ask the same question. I had a look at the source code and it seems that the only backup option implemented is the IMAP option. Also, adding a local backup option might not be trivial.

@jberkel Is it a feature you are interested in? I can work on a pull request.

This would be great! Once created a local backup in the local storage, the termux software can be used to analysis the message or call log and do anything I want. @Nicop06 do you have any plan implement this?

@chaoqing I completely forgot about that. I currently don't have time to work on it. I will update this issue if I find the time to start implementing this feature unless someone else wants to work on it.

What do you mean by "local backup"? Copying the data to a database/csv file?

On the sd card. So that it can be exported using cloud synchronization applications for instance.

I'd prefer (esp. for privacy reasons) not to store a copy of the user's data locally.

But uploading to Google is an A-OK privacy move?

It's already locally stored on the phone. We just want more flexibility with that.

@AeliusSaionji 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)

Aren't there already dedicated apps which just do local backups?

If there's a solution on Fdroid that still works on Oreo and supports restoring, I haven't seen it.

Specifically open source apps I don't know, was thinking of "SMS Backup & Restore" (which uses some XML format I believe)

A common use case would be migrating from an old to a new phone. Especially for users with google free phones.

@jberkel Privacy concern is exactly why I prefer to store locally.
Also, "SMS Backup & Restore" seems to have been sold to some company. Before it was a one man show - Ritesh Sahu, now SyncTech Pty Ltd controls the app.
There has been some bad precedents on companies buying popular small apps.
It would be great to have an option to store it locally ( internal sd, as external sd causes headaches for developers due to googles lack of proper code regarding external devices).
Regarding privacy concerns of local storage, a popup disclaimer could warn users about any privacy issues due to saving data locally, i.e. easily accessible to anyone etc.

I just want to add my voice to those requesting a local import/export. A trusted open source application is not in the same class as some shady app from the Play store that does who knows what with our data. A local file can be deleted after use. We would have to run a local IMAP server to be able to achieve that level of control with this app without local import/export, and that seems a bit of an overkill.

as a half workaround there is "slight backup"
https://f-droid.org/en/packages/de.shandschuh.slightbackup/
https://github.com/handschuh/Slight-backup
unfortunately already 5 years old and maintainer seems to be dead.
i was able to export smses. it produces an xml file. but i was not able to import. it just says import successful but no sms imported.

What about MMSes? Neither does SlightBackup nor SMSGate backup them. It would be useful to have sms-backup-plus to save them locally.

I suggest, if this is to be implemented, that it uses MailDir format, rather than combining multiple messages in an archive (eg, XML). That means you don't need to worry about combining or overwriting such files when you export, since every individual message is its own file with a UUID for a name.

This would behave similarly to an IMAP service, so it may simplify some of the coding needed.

Taking that one step further, one possible approach would be to install an IMAP server on the phone, as a separate app, with its own privacy policy. Does anyone know of such a thing?

@kurahaupo, Epistolaire has a SMS/MMS-JSON to Maildir converter, but this specific converter is written in Python. You might still be interested: https://github.com/hydrargyrum/epistolaire/tree/master/converters/maildir
Python interpreters exist on Android, and if the need arises, the converter could be ported to Kotlin with some effort.

Some of the design decisions were:

• each conversation on SMS/MMS app corresponds to one mail thread
• each conversation has a virtual root message which doesn't exist, i.e. it's not present in the maildir
• all messages in a conversation include a References header pointing to that root message
• this is useful for subsequent backups, the root message id always stays the same for a conversation, even in the case where a backup has no common message with a previous backup
• each SMS header Message-ID is a hash of sender + datetime, to have a stable id across backup

@hydrargyrum thanks for those very useful points.

I've added some improvement suggestions for you.

I'll look into how threading is currently implemented in SMS Backup+ to see whether these ideas can be incorporated.

channelling further discussion into #974

Storing it locally is easier, faster, more straightforward.
No dependency on Google services. No bothering with Google accounts. No Internet connection required.

See also: You don't control your data in the cloud