While this tool has been used to fix a number of bugs in Signal Android, it's more experimental features have also introduced issues in databases at times. When this happens, most often the backup will fail to reestore properly. Unfortunately, sometimes a flaw is introduced into the database that only causes a problem at some later point in time. If you believe you are running in to any of these and need help, of course do not hesitate to open an issue.
-
Main symptom: cloud backup fails to be created for a database that was previouly merged (with
--importfromthreads) with this tool.During backup merging, the column
ringerin thecalltable was not treated as referencing arecipient._id. This could cause an entry in thecalltable to exist with aringerthat reference a non-existing (or invalid) recipient.See #332 for details and a fix.
-
Main symptom: Signal crashes randomly for a database which was created by
--importfromdesktopand--importdesktopcontacts. The debug log wil show ajava.lang.AssertionErrorsomewhere inStorageForcePushJoborStorageSyncJob.While importing group-recipients from Signal Desktop, sometimes they have no
storageIDset in the Signal Desktop database, while this is a required column (storage_service_id) for the Android database. The tool erroneously imported these contacts anyway, setting thestorage_service_idtoNULL.A fix is to identify the offending recipient, and delete it (along with the thread for that group). See #341.
Alternatively, but untested: while a
storageIDwas not present when the contact was imported from Signal Desktop originally, it may be present now. In that case extracting that and updating the Android database should probably also work. Also, it may actually work to set thestorage_service_idto some new random 16 byte key.