I have:
When I send an SMS with MightyText, it appears in the conversation with that contact in Messages, but not in Signal.
Actual result: Message is sent. Sent message appears in conversation in Messages, not in Signal.
Expected result: Sent message should appear in Signal. (no comment on expected behavior re Messages)
Device: Samsung Galaxy S7
Android version: 6.0.1
Signal version: 3.22.2
I believe this indicates that Signal is not importing new messages from the system SMS database as they arrive. It should.
Note that this is the opposite of #5491.
This is likely the same problem as #5803, and related to #4037
Wouldn't it make more sense to just use Signal as the default SMS messenger in this case?
In addition to the other issues #5211 looks like a duplicate. Signal's database is separate from the system database for security reasons. Yes, it would be possible to read from the system's message store and in fact you can manually import from it, but displaying messages from two separate databases in the Signal conversations would probably be just too tedious a thing to maintain in the long run.
@jeremymasters I do use Signal as my default SMS messenger. That doesn't stop other apps (like MightyText, Google Now, etc) from sending SMSes.
@2-4601 there are plenty of issues here for users wanting Signal to read from and/or write to the system database. Other apps like MightyText have no problem keeping two databases. This doesn't seem "tedious" at all.
You could be right, Moxie will re-open if he sees that this should be implemented.
The reason why Signal doesn't use the system database is because the system database can't be encrypted. Since Signal offers app-level password protection, and in fact encrypts texts at rest by default (but leaves the encryption password blank on disk until it is set by the user), using two databases would defeat the whole purpose of at-rest encryption - the attacker could simply read the unencrypted system database.
@nrizzio I think you're in the wrong issue. This issue is about reading messages put into the system database by other apps, not about writing sent-by-Signal messages into the system database.
@sparr That'd be cool, but it is tedious. There are a bunch of edge cases, like we support importing your SMS database (so that it can be encrypted and you can delete messages from the system SMS database), but if people import it and don't delete those messages from the system database, then they'd see duplicate messages.
We could drop import all together, but we also have a pretty different database schema now, so merging the two cursors together would be non-trivial, and it would at minimum mean four DB queries every time you open a conversation. MMS would probably be an absolute nightmare.
It seems like it'd be worth it if we wanted to go back to a world where all SMS/MMS is stored in the system database, but it'd be a lot of work just to catch an edge case like this one that doesn't affect most people.
Duplicates are a trivial problem to solve. Every major SMS backup/restore program does it automatically.
I think querying the DB every time you open a conversation is a poor approach. Rather, the app should register an intent to be notified of SMS entries being added to the system database, and catch them one at a time that way. That's how all the other "do something when I get an SMS" apps work, as mentioned in the other related issues here.
Go for it!
That's all I needed to hear :)
It looks like we're going to need to use a ContentObserver pointed at content://sms/sent
something like this, but updated for newer Android APIs:
I've got to figure out how to compile and test the app, then I'll take a crack at making this work.
ContentObserver isn't going to work while the app isn't running
While the app isn't running we don't much care what it can't do, right? The observer will pick up recent additions to the database as soon as the app is opened... I think.
Sadly I might be abandoning this idea. I was very motivated to get it working, but installing a self-compiled version of the app resulted in all my messages getting deleted and my keys being lost, so I've lost most of my desire to keep using Signal at this point.
A ContentObserver will not tell you about things that happened when the observer wasn't registered.
Good to know. I guess that means polling the ContentProvider ourselves, maybe when the app starts up, maybe when a conversation is loaded?
You could do that, but now you're full on into de-dupe territory or two extra queries per conversation load. You think that's trivial, so I'll be looking for your PR. =)
Most helpful comment
@sparr That'd be cool, but it is tedious. There are a bunch of edge cases, like we support importing your SMS database (so that it can be encrypted and you can delete messages from the system SMS database), but if people import it and don't delete those messages from the system database, then they'd see duplicate messages.
We could drop import all together, but we also have a pretty different database schema now, so merging the two cursors together would be non-trivial, and it would at minimum mean four DB queries every time you open a conversation. MMS would probably be an absolute nightmare.
It seems like it'd be worth it if we wanted to go back to a world where all SMS/MMS is stored in the system database, but it'd be a lot of work just to catch an edge case like this one that doesn't affect most people.