Signal-android: Media Not Exporting to XML

[alexh3791]

I have noticed that when exporting a plaintext backup in the current Play Store version of the app, all media attached to messages (and perhaps even the text from messages containing media) is not included in the XML backup, even though 'SMSBackup And Restore' backs up the media with all messages properly when creating an XML backup, and can restore the same data.

Since I use both TextSecure and SMSBackup And Restore in my system to back up a record of my messaging activity, I need media to be included in my plaintext backup alongside text messages.

[moxie0]

Didn't realize SMS B&R supported media now. Maybe @mcloo can take this on.

[alexh3791]

@moxie0 @mcloo Awesome! I'd love to see it implemented. I'd help if I could!

[McLoo]

@moxie not until next weekend. Got to figure out how media is exported. I guess Base64.
Would also need a short description how to access the MMS fields to safe some research time.

[alexh3791]

Has this been resolved?

[McLoo]

Not yet unfortunately. But I do eager researching already.
Though I still hope for some hints on getting the media data @moxie0 or @mcginty maybe?!

[mcginty]

@McLoo check out the setMediaMmsAttributes(MediaMmsMessageRecord) method in ConversationItem to see how you can check for and retrieve media "parts" to a message.

[diego0815]

@McLoo im trying not to nag... but is there any news regarding this? I'm waiting for that feature for some reason ;-)

[McLoo]

@diego0815 just go on nagging. I always need some trigger ;)

I was waiting for @mcginty to finish the makeover of the export process to go on. I guess I could at least go for the import part already...

[diego0815]

@McLoo that sounds great, yepp I also sometimes need this kick in the ass, just feeling bit bad nagging guys who are doing such great things in their spare time ;-) but as long as you appreciate an occasional nag, I'll gladly do so B-)

I'm waiting for media export, so I can get my messages exported, then all wiped ( to fix 814 for me) and then re-imported...

[alexlance]

I put a simple dump file here that reliably fails. There are three messages in it, 2 sms, 1 mms. The mms doesn't import.

http://alexlance.com/TextSecurePlaintextBackup.xml

Would love to get this issue fixed so I can bring all my existing messages into textsecure.

Let me know if I can provide any info or assist in any way. I also commented on #1410 which is probably a dupe of this issue.

[McLoo]

@alexlance MMS are totally ignored right now. The import for them has to be implemented first. So it's more a missing feature than a bug ;-)

[alexlance]

@mcloo may I suggest that it is very surprising behaviour for the
application to behave as though the import was successful, but to have
silently not imported all of the image/mms messages.

And unfortunately after an import into textsecure the user is very
likely to go and delete their messages from the android system sms
database - thus permanently losing the image data.

Are there any plans/timeline to implement this functionality?

[diego0815]

@alexlance as i understand it's being worked on, and its depending on some other prerequisites.
So i'd say its done when its done, but we got a right to nag from time to time ;-)

[alexlance]

@diego0815 Frankly - the user that is getting software for free does _not_ have a right to nag :) but this particular issue stops me from using textsecure as my default messager.

And it might be a missing feature that it doesn't import mms, but it is a _bug_ that it doesn't report an error to the user, saying: Hey everything was imported just fine, except these messages...

Presumably the textsecure dev team have some sort of roadmap of priorities - it'd be lovely to get an indication of when (or if) textsecure will support importing mms/images.

[diego0815]

@alexlance totally agree lets see when we will get what we are craving for (hint @mcloo ;-)

[alexlance]

@mcloo any chance of getting an idea of whether this functionality will be added?

[McLoo]

@alexlance I wish I knew. Work is pushing me quite hard these days. To much to work on such a change right now. 😢

@mcginty what about the rewritten import/export? Dropped?

[alexlance]

@mcloo ok thanks for letting me know. It's such a bugger, because I would love to switch over to TextSecure and delete the system message store, but I can't just discard all the old mmses - a picture is worth a thousand words :)

[Eric1911]

I just installed TextSecure (v 2.2.0) and love it, but was disappointed that my MMS images didn't import along with the SMS text from the Android (v 4.4.4) Messaging (v 4.4.4-24) app. I think this is the right topic to chime in and vote/beg for additional MMS functionality in TextSecure. Thanks for a great app!

[MarcRdC]

Any progress on this issue?

[McLoo]

sry. no more but a growing feel of shame for not touching this.

[MarcRdC]

@McLoo Nothing to be ashamed of; it is understandable that other things have more priority. Nonetheless, the import‐export feature would ease the switch from other SMS apps and would supply a nice way to comprehensively backup all messages (no loss in either case).

[mrdanbrooks]

+1 for this feature. I've been watching this issue for over a year, it is the only reason I have not switched to TextSecure yet.

Does anyone know how SMSBackup And Restore serializes their image data?

[p2004a]

Very similar situation as above. I'm waiting for this feature for more than a year too. I even have two phones. I don't use the second one but I still can't wipe out all the data from it because there is a TextSecure with all my messages. (of course I could do it manually but it would take a long time I'm not willing to waste so much of it..). Possibility of backing up this type of data is very, very important and I don't really care if the backup is encrypted or not. If it is not I will just encrypt it with other tool.

[alexlance]

+1

[alexlance]

Hi @mcloo and @mcginty and @moxie0,

Australia is moving over to mandatory data retention laws soon, which will include text
messages. And I suspect there will be a rise in the number of people wanting to migrate
to a secure messaging platform.

As this issue directly impacts users who are looking to migrate to a new messaging platform,
may I request that we get the ball rolling and discuss what would be required to get this
functionality implemented?

[spectas]

+1

I would love to see this feature!

[agrajaghh]

@spectas Please only post comments in issues if you have new information to add. This isn't helpful and is just time consuming for the devs

[alexlance]

Just realized, I'd broken the link to this file:

http://alexlance.com/TextSecurePlaintextBackup.xml

It's back up now. There are three messages in it: 2 sms, 1 mms. The mms doesn't import.

Cheers,

[alexlance]

I emailed the SMS Backup & Restore authors, requesting some information about the output XML format for handling MMS messages. It's only been a couple of days, will post response here when received.

---

Date: Thu, 21 Jan 2016 16:52:50 +1100
To: [email protected]
Subject: xml documentation for SMS Backup & Restore

Hi there,

I'm a developer that is keenly interested in seeing a particular
Textsecure/Signal bug resolved:

https://github.com/WhisperSystems/Signal-Android/issues/1619

Textsecure/Signal is an SMS app for android. One of its features is the
ability to dump out/export all the text messages in a format that is
compatible with Carbonite's SMS Backup & Restore.

Unfortunately at the moment, the TS/Signal app only exports the text
messages, and the picture and MMS messages get skipped over.

I suspect it could increase the likelyhood of fixing the above issue, if
the specification for the SMS Backup & Restore XML dump file format was
published somewhere... (especially the bit that documents MMSes) is it
available by any chance?

Kind regards

[alexlance]

...and never got a response. @mcloo is all hopeless, should this issue just be marked as wontfix?

[mrdanbrooks]

Try pinging the developer one more time. It is possible they were busy and your email simply got pushed far enough down their stack that it was lost.

Even if they don't reply, I don't this this is rocket science. The image data has most likely been simply marshalled into a text compatible format, probably using an existing library to do so. Maybe at some point I will take at stab this by trying various known deserialization methods on the data to see if any of them produce a viewable picture. Once we know how to deserialize/serialize the images someone more familiar with this software can integrate the functionality in.

Can you fix your xml sample link? Also, is the MMS an image?

[McLoo]

Yeah, just go on pinging. Most of the time I have ToDo tabs in my browser - till it crashes :)

@alexlance the MMS import isn't implemented in signal at all. So you won't get text or media from the XML.
My last investigation on this, showed the MMS data is pulled base64tified from the system into SMS B&R files

                if (!TextUtils.isEmpty(partsCursor.getString(partsCursor.getColumnIndex("_data")))) {
                    StringBuilder partsData = PartsHelper.getBase64Data(context, partsCursor.getLong(partsCursor.getColumnIndex("_id")));
                    if (partsData == null) {
                        exportResult = Boolean.valueOf(true);
                        StringBuilder stringBuilder = new StringBuilder("");
                    }
                    serializer.attributeBase64("data", partsData);
                    partsData.setLength(0);
                }
                serializer.endTag("", "part");

So once we figured out how to get media data from system's MMS store into Signal's, we can (quite) easily handle the XML Import.
Exporting it the compatible way is another thing...

Edit: If someone is still interested in taking on this, maybe some reverse engineering with jadx and a sms b&r apk would be of use.

[alexlance]

@mrdanbrooks I've attached the file directly to this ticket. The file contains three messages in it: 2 smses and 1 mms (an image).

@McLoo The file attached is in the xml format that SMS Backup & Restore dumps them in. If Signal could import this xml file format, then all would be good as far as I'm concerned (Signal exporting function could happen later on).

Whilst the actual format of the image is probably just base64 encoded, the structure of the xml document - the "parts" and the meaning of the attributes in the mms tag are a little tricky to understand eg:

<mms text_only="0" sub="null" retr_st="null" date="1406695762000" ct_cls="null" sub_cs="null" read="1" ct_l="null" tr_id="null" st="null" msg_box="1" address="0444444444" m_cls="personal" d_tm="null" read_status="null" ct_t="application/vnd.wap.multipart.related" retr_tx t_cs="null" d_rpt="129" m_id="[email protected]" date_sent="0" seen="0" m_type="132" v="18" exp="null" pri="129" rr="129" resp_txt="null" rpt_a="null" locked="0" retr_txt="null" resp_st="null" m_size="null" readable_date="30 Jul 2014 14:49:22" contact_name="B"

The folk at Carbonite (who author SMS B&R) know what they mean. I'll ping them again, it is after all, in their interests to have other applications that are compatible with their application.

TextSecurePlaintextBackup.txt

[moxie0]

Those fields are just the names of the columns in the system MMS database schema.

[Fmstrat]

+1 - Following.

[moxie0]

@Fmstrat Please do not bump issues: https://github.com/WhisperSystems/Signal-Android/blob/master/CONTRIBUTING.md#dont-bump-issues

[Fmstrat]

Since we're not getting feedback from the SMSB&R group, Signal "attachments" won't have the associated metadata that would be required in the smsmms.db schema, and this ticket has been around for nearly 2 years, I'd like to propose an enhancement to ensure that images in Signal messages are at least included in the backup.

Even if the import doesn't bring them back in appropriately, those users that backup their XML to a secure location and clean their phone will at least have access to the base64 images if required. This could also be a first step to getting attachments exported from Signal imported back in if a user changes devices.

Two potential methods:

• Export in SMSB&R MMS format with nulls: This would involve using the multipart MMS format that SMSB&R already uses, but with null entries for metadata that is MMS specific. Going this route seems the most expansive route for future export/import functions, but may break importing through SMSB&R to the SMS system. Going this route would require testing to ensure that isn't the case.
• Export to ignored XML: This route would export attachments in an XML tag that would be ignored by SMSB&R and by Signal during the already existing imports. This means that the attachments would be in the XML for later use (so users don't fully lose the data) but would not be actively imported at the time of release. Future imports could leverage this format for Signal attachments, since they vary from MMS attachment types, anyway.

If either of these are acceptable to the Signal team, I am willing to fork off and attempt to dive into one or both of them deeper to see if they are feasible. Please let me know. Thanks.

[Fmstrat]

Since there hasn't been a response here I'm thinking about the ignored XML route. At first glance it appears the export just loops through the SmsDatabase object, and adding a loop to the AttachmentDatabase with some base64 encoding may be all that is required. I'd basically just make a record that looks something like this with all of the fields from the attachment DB:

<signalattachment ... base64data="<BASE64DTA>"/>

This appears to be skipped if it was imported to a standard SMS client (need to do some more testing but initial attempts look good), but the import for Signal could be updated to pull it into the attachment database.

Would love to hear from the Signal team to make sure it's something they would pull in before I invest any more time into this. Thanks all.

[moxie0]

It needs to use the SMSB&R schema. It's just using the fields from the system MMS DB schema, we should do the same.

[Fmstrat]

@moxie0 Is that even possible since Signal allows for more attachment types than MMS?

[moxie0]

I'm not sure what you mean. What does Signal do that isn't supported by the system MMS database?

[RiseT]

While it seems to be difficult to get technical info from a big commercial (publishing) company like Carbonite, you might have more luck contacting the app's original (and present?) developer. I've done a bit of "research" (i. e. I've googled for a while...) the last couple of minutes. If I'm not mistaken, the original developer of SMS Backup & Restore is

Ritesh Sahu
https://twitter.com/hardkikker
http://android.riteshsahu.com/
https://play.google.com/store/apps/details?id=com.riteshsahu.SMSBackupRestore

Hope this helps & good luck :smiley:

Edit:
Btw. - I've noticed that there's another app with the same name and similiar functionality - which seems to be XML-based as well (do they possibly use a compatible database format?):
https://play.google.com/store/apps/details?id=com.gizmoquip.smsbackup

We're talking about Carbonite's/Ritesh's app, right?

[jrudolph]

I tried to build a first attempt of exporting MMS to the SMSBR's XML format: https://github.com/jrudolph/Signal-Android/commit/23fcb744d814630413b0aa4fc2f97d8ec431eb73

It seems to work almost. SMSBR can import the data without errors but the images can not yet be viewed in the regular message app. Instead they just show up as blank frames. It is possible, though, to copy the attachments over from the attachment directory of the message app and view them using a computer, so it seems there isn't much missing to get it to work. Not sure when I'll be able to continue work on this, so I'll put it here. If anyone wants to try, you may use this as a starting point. (Code will need lots of cleanup in the end but it's probably still easier to start from something than from nothing. There's another problem that conversations will not be correctly associated for all messages.)

[rmgk]

I also made an attempt at implementing backup and import for group messages and media messages with code here.
This is based on this pull request by @AsamK and some subsequent edits by @merkste.
I somehow missed the code from @jrudolph probably because this issue title is missing a "backup" keyword.

Behavior of my current solution

• Same problem @jrudolph mentions, media files are not displayed by the MMS app after import into the system database. Should work now.
• Importing MMS into Signal worked (both for imports from SMSB&R as well as from Signal itself).
• Exporting and importing of group conversations seems to work. Neither group names nor avatars are exported. I did mange to rejoin a group after getting a new identity, and importing backups.
• Importing MMS group chats seems to also work.

Caveats

• I have only limited understanding of MMS and Signals database formats. The implementation is based on guessing and trial & error.
• I only tested with my data, other backups may break.

[merkste]

Nice. I have some nearly finished backup code, too. Personal circumstances
prevented me from finishing it yet. But I can provide you the code, if
that would be helpful.

[flokli]

@merkste I'd also be interested in this code, and could help in polishing it :-)

[merkste]

@flokli Here it is: https://github.com/merkste/Signal-Android/tree/backup_mms_text Please keep in mind, that it is unfinished and hasn't been touched for a while. I'd be happy to here from you about your progress. Maybe we can go ahead together once I'll manage to free some time.

[floriangosse]

@merkste how is your progress?

[rmgk]

@floriangosse my branch (which is based on the work of @merkste ) still works as described above. I can only add that I occasionally rebase it on top of the newest version of signal and use it to do regular backups. I did not test restoration since my initial tests :-).
Another thing I did not mention before is that the code does uses the Telephony API constants, which seem to be missing in Signals minimum required API level, so those would probably need to be replaced.

[ubergeek77]

Is a solution for this issue planned? Nearly three years later, it is still a problem on the latest version of Signal. Neither MMS images are exported, nor are images sent encrypted through Signal.

[janvlug]

@ubergeek77 I understand that you are interested in progress on this issue, or that you might be worried that the issue is forgotten. I myself am quite often tempted to ask for status updates in issues as well. However doing so consumes costly time of the limited number of developers. This issue tracker is really for reporting issues or adding new information to already reported issues that might help solving them.
You can always discuss issues and ask for status updates in the community forum at: https://whispersystems.discoursehosting.net/

[turion]

@ubergeek77 Signal does not encrypt images?? If that's true, that's a separate, very serious issue that has to be reported.

Edit: thanks @Fmstrat and sorry for the noise.

[Fmstrat]

@turion He means that both encrypted Signal and unencrypted MMS images are not in the backup.

Sorry for the tack-on, despite me thinking this should be a hot feature, I wouldn't have other than I didn't want that comment to run wild.

[Kazpers]

@rmgk Have you submitted a PR for your code (and has it been approved/rejected)? It seems to me that a full (unencrypted) backup that works for restore in SMSB&R is the crucial first step that Moxie has mentioned many times. Once that's accepted in the code work can be done on encryption (and in the meantime it'll allow (with proper warnings that it's not safe) backup and restore for people desperately needing it to move phones.

If it isn't accepted into the main codebase the risk is that it'll eventually be lost and work on this issue will have to start over almost from scratch again.

[rmgk]

No PR was submitted yet. The contributing Guidelines ask to only submit complete PRs.
Last time I checked, I think the code still uses some API calls which are too new, it is basically still untested except for me restoring my installation once (which worked, including groups and images. but not group names nor group pictures. no other files were tested).
It is also a big pull request based on code by both @AsamK and @merkste, and I have no clue how to best handle that (CLA, bitbucket, should I squash the commits …)
If someone wants to help by testing that the code backup actually works for them, that would be much appreciated. I still rebase my branch to the newest version every once in a while. I still plan on doing a PR, it is just not very high priority (as backups currently work for me™ :smile:)

[flokli]

@rmgk: I just took a quick look at your fork.

Seems like something got wrong when you rebased the .gitignore, and you probably want to keep things like this in a global .gitignore, but anyways ;-)

Your changes currently consist of 54 different commits, which are hard to review individually. Maybe you could try to combine those into logical units, and fixup 'fixup commits' to the original commit, to get the number down.

Also, there are things you decided to do diffently at a later stage, like https://github.com/WhisperSystems/Signal-Android/commit/88f0601537a991ff8f6cddbb92f9a5303a3e024f. Probably you should squash things like this together with when you introduced the initial code, so it looks like you used those constants from the beginning.

[strugee]

Also, there are things you decided to do diffently at a later stage, like 88f0601. Probably you should squash things like this together with when you introduced the initial code, so it looks like you used those constants from the beginning.

I personally never squash things like this together because it permanently destroys data about how a feature evolved over time. That being said, squashing typo commits, etc. is fine IMO, and ultimately if the project maintainer (i.e. Moxie) decides that they'd prefer for those to be squashed, they're the one that gets to make the decision.

[flokli]

Fair point. This really depends on the maintainers decision.

@rmgk I will try to give your branch a test spin in the next days, will report back.

[fdw]

Can I do anything to help this PR along? I'd like to have this feature...

[alexlance]

Can I suggest that we begin organising the ten year reunion for this particular issue? I'm sure we'll all know each other very well by then. Be great to sit around, grab a beer and reminisce about that time we tried to use a secure messaging platform, but no one had both the brains and energy required to lower the barrier to entry on the fucker.

[Kazpers]

I honestly do not know why this does not have priority. Personally I've introduced close to 10 people to Signal.

They all loved it.

But not a single one of them are using it anymore because after the first time they get a new phone and realize all their mms are lost this app is dead to them. So I'm now the only one using it making its encryption pointless.

Honestly I'd do this myself if I could, however I have exactly zero experience coding for Android. I cannot stress enough how important this issue is, however!

[Grunthos]

Is there an official status on the @rmgk version? Would love to see this feature and am happy to help with coding, testing, etc etc.

Any chance of a road map of what is needed so those of us who find the lack of backup one of the most appalling mis-features of Signal can do something about it?

[breznak]

After reading through the thread and seeing the bug is 3yrs old, I'd like to suggest a minimalist approach:

• not encrypted backup (current export is also plaintext?), users can encrypt themselves
• not necessarily SMS B&R compatible
• just offer to dump all media in a conversation to a folder
  
  
  
  • and for import append those media to the conversation (timestamps don't even have to be solved, just make them all appear as of the date of the import/export)
  
  

[fdw]

I'm not sure if I understand your suggestion correctly, @breznak : Should the media be part of the plaintext encryption (base64-encrypted)? Because then, the separate export of all media is not necessary.

Regarding point 3, the export of all media of a conversation was once supported, but is currently not (see #7097)

[breznak]

Should the media be part of the plaintext encryption (base64-encrypted)? Because then, the separate export of all media is not necessary.

Actually that is a good idea, if it's easier! I wasn't thinking of a plaintext export of media encoded as bas64-encoding.

Ad point 3: yes, all my activity was about the feature of "Save/Export All media".

[eipiminus1]

The Signal-Desktop app just transitioned from Chrome App to standalone. In the process of moving from one to another, you have to create a backup (unencrypted) that contains all messages, media and keys.
Maybe this format could also be adapted for the mobile client backups. This might even allow data exchange between mobile and desktop at some point. Unfortunately the export button is only available in the old Chrome app but not in the new standalone version which suggests that the Desktop team sees it purely as an intermediate solution for transition.

Maybe @moxie0 or someone from the OWS team could give us a hint if this is worth investigating further. I do not mean to unnecessarily ping for attention but I believe that some clear guidance on what is expected for a pull request to be considered, would be a huge motivator.
Currently i understand that

the OWS team wants:

• full compatibility with SMS B&R
• encryption

The community (only my impression based on what I read):

• does not fully understand the need for SMS B&R compatibility
• prefers simple, unencrypted backup over no (media) backup at all
• struggles finding good documentation on the SMS B&R format for media and thus to write a robust backup system based on it.
• is motivated to contribute but lacks time (who doesn't?) and guidance to produce merge-ready code

I personally think:

• Reusing a format that already has wide adoption (like SMS B&R) is generally a better idea than inventing some own, poorly documented format
• Even better would be a well documented format (maybe this could be a requirement for the pull request?)
• regarding the encryption of the backup: By default the message database is unencrypted for a while now, since those users that care about security could simply enable the full disk encryption provided by android. [1] The same logic would apply to the backup, right?
• I strongly believe that a fully working backup is a lot more important than a fully featured backup. My phone is slowly dying but as of right now I see (almost) no way to save the conversations. (Trying to compile one of the modified versions above is probably the best shot right now.) That's frustrating

I hope this helps to advance the discussions between community and OWS.
It's a great product that I love to use and promote of course! Thanks for that :)

[1] https://github.com/WhisperSystems/Signal-Desktop/issues/452#issuecomment-162622211

[Grunthos]

Sounds excellent to me; I am happy to donate time and effort (coding) to this, but only if we have a genuine likelihood of whatever patch being accepted. There have been too many genuine efforts lost and discarded in the past to give me great confidence in the process.

Plain text export of text and images is vastly superior to the current offering.

[xyzzyxw]

No useful backup functionality is such a major drawback of Signal. Currently I don't recommend it to anyone anymore because of this.

I don't understand why compatibility to SMS B&R is required, as it seems to be a huge problem. I have never heard of that app before and also don't know anyone who has.
Just drop that requirement and implement a working backup. I don't care about the format as long as it works.

[fengshaun]

Is there a reason why Signal needs to export its data in a manner that is compatible with an undocumented xml format used by a proprietary application? I understand if the authors use that app and won't work on alternatives, but it seems like other solutions are rejected specifically due to incompatibility with this undocumented format.

[SolidTux]

I'd really like to help with this, but I don't see what has to be done next. Would it be possible to summarize the steps to archive the full backup?

[FeuRenard]

Here is a community forum thread with some recent discussion:
https://whispersystems.discoursehosting.net/t/encrypted-backup/1227/27
Further discussion should happen on the community forum, not here on Github.

[stefan-schiffer]

text backup to xml-file does not work either. it exports only messages from others (those from myself are not included) and includes characters incompatible with xml-parser (see chrome's error message below).

[strugee]

@stefan-schiffer those seem like separate bugs unrelated to this one. You should search for duplicates and file separate issues for each bug if you can't find any already existing.

[breznak]

@Roghetti Thank you so much for your contribution! 👏 Qucikly reviewed and it looks great. Hope the PR gets the attention it deserves and will be merged soon.

[Fmstrat]

@Roghetti So happy to see someone contribute on this one. Out of curiosity, can your method be used for archiving? I.E. keeping the backup file offsite, and then using the export in a viewer outside of the Signal App?

A use case example would be that I've created a Web based message viewer that allows me to go back and view old messages from Signal and Google Voice exports.

[stefan-schiffer]

@Fmstrat Does your solution work with the current text-backup? Maybe similar like this: https://mattj.io/sms-backup-reader-2/main

Could you please post a link to your viewer? I'm very interested on an offline solution too.

[Fmstrat]

@stefan-schiffer Yes it does, but it parses the files for both SMS backup (Signal) and Hangouts (need to update for Voice) into a database. It has a lot of personal info in the code so it's been just for me. Perhaps I could debrand it for you. Please start up a conversation on https://whispersystems.discoursehosting.net vs here, though, and I'll look into it.

[stefan-schiffer]

@Fmstrat Thx for the info.

[Amalinda]

I made an effort to move from WhatsApp to the signal along with my family. After realising lack of media back up, I had to revert back. Did I miss how it's done?

[ckujau]

Full backup/restore is coming to Signal with commit 24e573e537639f6f8ff40fd774cf9ff079bbacce ("Support for full backup/restore to sdcard"), which landed in the Beta releases already - yay! That should also solve issue #6539 I suppose.

[Fmstrat]

@ckujau Great news, thanks! Any idea when it will come out of beta? Unfortunately I'm not in the beta program and would need the export to switch over. ;) Picking up an S9 tomorrow so won't have the S7 much longer to export.

[automated-signal]

GitHub Issue Cleanup:
See #7598 for more information.