[GH-ISSUE #974] Feature request: save to local file

kerem commented

2026-02-26 01:31:51 +03:00

Owner

Originally created by @hydrargyrum on GitHub (Aug 17, 2019).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/974

It might sound out of scope for this app, but it would be nice if it were possible to export SMSes to a local file instead of only imap/gmail. It's SMS backup so it can still fit in this app.

For the format, there's a "de facto standard" XML used by non-opensource app sms-backup-and-restore.

Originally created by @hydrargyrum on GitHub (Aug 17, 2019). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/974 It might sound out of scope for this app, but it would be nice if it were possible to export SMSes to a local file instead of only imap/gmail. It's SMS backup so it can still fit in this app. For the format, there's a "de facto standard" XML used by non-opensource app sms-backup-and-restore.

kerem added the

feature-request

cloudless

labels

2026-02-26 01:31:51 +03:00

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@lesmana commented on GitHub (Sep 20, 2019):

duplicate of https://github.com/jberkel/sms-backup-plus/issues/749

@lesmana commented on GitHub (Sep 20, 2019): duplicate of https://github.com/jberkel/sms-backup-plus/issues/749

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@Techwolf commented on GitHub (Feb 1, 2020):

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.

@Techwolf commented on GitHub (Feb 1, 2020): 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.

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@hydrargyrum commented on GitHub (Feb 12, 2020):

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 commented on GitHub (Feb 12, 2020): 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](https://f-droid.org/packages/re.indigo.epistolaire/), and [github repository](https://github.com/hydrargyrum/epistolaire)

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 3, 2020):

@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.

@kurahaupo commented on GitHub (May 3, 2020): @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.

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 3, 2020):

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

@kurahaupo commented on GitHub (May 3, 2020): Do you think it would be useful to share a common library?

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@hydrargyrum commented on GitHub (May 3, 2020):

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

@hydrargyrum commented on GitHub (May 3, 2020): @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](https://github.com/hydrargyrum/epistolaire/tree/master/converters/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](https://github.com/hydrargyrum/epistolaire/blob/master/LICENSE) so you can do whatever you want)

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 22, 2020):

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.

@kurahaupo commented on GitHub (May 22, 2020): 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.

kerem commented

2026-02-26 01:31:51 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 28, 2020):

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 ...

@kurahaupo commented on GitHub (May 28, 2020): 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 ...

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@kurahaupo commented on GitHub (May 28, 2020):

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)

@kurahaupo commented on GitHub (May 28, 2020): 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)

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@ell1e commented on GitHub (Jun 9, 2020):

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 commented on GitHub (Jun 9, 2020): 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)

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@kurahaupo commented on GitHub (Jun 11, 2020):

@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.

@kurahaupo commented on GitHub (Jun 11, 2020): @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](/pintspin/ReadSMSpublic) _NB: I'm only a minor contributor; it's up to the principal developer @jberkel to say for sure._

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@kurahaupo commented on GitHub (Jun 14, 2020):

@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.

@kurahaupo commented on GitHub (Jun 14, 2020): @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 1. the envelope cannot match the actual message, so it would fail (probably invisibly) when using a DMARC signed domain. 1. on the plus side, the RFC-822 format is exactly that used by IMAP, so some code could be reused.

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@h2oforlife commented on GitHub (Sep 30, 2020):

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.

@h2oforlife commented on GitHub (Sep 30, 2020): 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.

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@kurahaupo commented on GitHub (Sep 30, 2020):

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

@kurahaupo commented on GitHub (Sep 30, 2020): @rubensudos see the local-save solution by @pintspin mentioned above (and in closed ticket #979).

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@h2oforlife commented on GitHub (Sep 30, 2020):

@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.

@h2oforlife commented on GitHub (Sep 30, 2020): > @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.

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@hydrargyrum commented on GitHub (Sep 30, 2020):

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

@hydrargyrum commented on GitHub (Sep 30, 2020): self-advertising: @rubensudos https://f-droid.org/packages/re.indigo.epistolaire/ backups sms and mms locally and is open-source

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@h2oforlife commented on GitHub (Sep 30, 2020):

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?

@h2oforlife commented on GitHub (Sep 30, 2020): > 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?

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@kurahaupo commented on GitHub (Oct 2, 2020):

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 will "just work".

@kurahaupo commented on GitHub (Oct 2, 2020): 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 will "just work".

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@HT-7 commented on GitHub (Mar 10, 2025):

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!

@HT-7 commented on GitHub (Mar 10, 2025): 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!

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@HT-7 commented on GitHub (Mar 10, 2025):

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.

From #749:

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

That's why lock screens exist. Data in internal storage is inaccessible without unlocking the phone. The data is under the control of the end user.

If you're so concerned, maybe let the user put it in an encrypted ZIP file.

@HT-7 commented on GitHub (Mar 10, 2025): > 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. From #749: > I'd prefer (esp. for privacy reasons) not to store a copy of the user's data locally. That's why lock screens exist. Data in internal storage is inaccessible without unlocking the phone. The data is under the control of the end user. If you're so concerned, maybe let the user put it in an encrypted ZIP file.

kerem commented

2026-02-26 01:31:52 +03:00

Author

Owner

@HT-7 commented on GitHub (Mar 13, 2025):

From #1046:

Sign in with Google temporarily disabled for this app
This app has not been verified yet by Google in order to use Google Sign In

Things like these show once again why an option to export locally is needed. It does not depend on an external account system to work flawlessly.

Dependence on an online service for something that could just as well be done locally = digital tenancy.

Just cut out the middleman entirely.

@HT-7 commented on GitHub (Mar 13, 2025): From #1046: > Sign in with Google temporarily disabled for this app > This app has not been verified yet by Google in order to use Google Sign In Things like these show once again why an option to export locally is needed. It does not depend on an external account system to work flawlessly. Dependence on an online service for something that could just as well be done locally = digital tenancy. Just cut out the middleman entirely. * [Digital tenancy: Why you don't really own your digital life - Android Authority](https://www.androidauthority.com/digital-tenancy-1120084/) * [You Can't Control Your Data in the Cloud - Karl Voit](https://karl-voit.at/cloud/)

Rows
Columns

[GH-ISSUE #974] Feature request: save to local file #774