I noticed, that the getInstanceFor(XMPPConnection) method of the OmemoManager is currently broken, which is quite annoying.
Until its fixed I'd suggest, that your client takes care of generating, storing and providing the deviceId of user accounts, since OmemoManager.getInstanceFor(XMPPConnection, deviceId) should work as intended. Calling getInstanceFor(XMPPConnection) should be avoided for now.
I think your method looks quite good to overcome the issue for now. I'll see if I can push a fix during the week.
I hope this helps you
Did you manage to implement a solution to overcome the problem that occurs in aTalk scenario case; and a snapshot release that include your fix?
Unfortunately not yet. I'm quite busy right now, since I'm participating in the Google Summer of Code, so fixing the bug unfortunately has relatively low priority right now. I'm open for proposals how to fix the issue though and pull requests are obviously welcome .
When aTalk starts up with a empty sql omemo tables, the omemoDevice ID stored by the statement
in the aTalk own implemented method above is not being used by OmemoManager. It was found that all subsequent access or creation of any omemo data e.g. preKey, signedPreKey, identities etc by OmemoManager uses a different omemoDevice with same bareJid but different deviceId.
See attached omemo sql tables. The unused omemoDevices are with currentSignedPreKeyId == 0 and lastPreKeyId == null.
With the exception of the unused omemoDevices being left in the sql table, all Omemo operations are working on aTalk.
Just uploaded an official release for aTalk version 0.8.2 to support OMEMO chat. Anybody who are interested to try out may download it from