Currently OmemoConfiguration#IGNORE_STALE_DEVICES is default to true.
If two OmemoDevices have not been sending omemo messages for the last 7 days to each other, it is not further possible for either of them to unlock the IgnoreStaleDevices state.
There is also no feedback to the application upper level when this happened; so as to allow app to prompt user to take the appropriate action.
Alternatively Omemo may intelligently recover from this situation. otherwise this option offers little benefit to user. May be the lastMessageDate should get updated when an Omemo message has been received without the need for it be decrypted first. But no sure if this has breached any security.
Are you sure about that? I’m pretty sure the device transitions from stale to active once it (re-)publishes its device ID.
Edit: You may be right though in cases where only one device exists. In such case the device list would never be cleaned from stale devices, so the device would never republish its ID… Gotta have to talk to Daniel about how Conversations handles that.
As a temporary workaround you may set IGNORE_STALE_DEVICES to false though.
Yes, I have already set it false to in order to continue testing. The problem caught me by surprised. Initially I was thinking it was my problem, as I had made major changes to aTalk source for the smack NoResponseException to see if it improves the situation. Finally spent one full day to trace to root cause of IgnoreStaleDevices.
{20180606]
Any update on the issue. I would like to include it in aTalk if the problem has been fixed.