Found that OmemoManager#PEPListener deviceListUpdateListener() did not manage to process the following pubsub#event sent from server due to late in PEP_NODE_DEVICE_LIST_NOTIFY listener registration.
aTalk has implemented the reflection method, and it is being called immediately upon xmpp connection to resolve the problem for smack 4.2.1-beta2-SNAPSHOT.
Continue testing with the OmemoManager#deviceListUpdateListener() after the reflection private method implementation. In smack omemo deviceListUpdateListener() handling upon receipt of an deviceList stanza, it will perform
in which it will update the “activeDevices” and “inactiveDevices” list with the received omemoDevice ID’s; in the persistent storage. The update does not checked for any new deviceID nor make new entry in the entities table if any. Under the smack omemo default file based backend storage, this works fine as the actual entities information can be added at a later stage (not sure when and how smack omemo update the entities info - guess it is during olmMessage sending?).
aTalk however implements omemo persistent storage using SQLite database, update the device active state without any entry in the entities will fail. If needs to, aTalk can perform check in the below override method and create new/missing entry in the entities table while updating its active state.
Would smack omemo considers enhance the deviceListUpdateListener() method to take care the above scenario i.e. create new identities entry if missing before calling active state update.
I created a new entry in the identities table for the new deviceId leaving keyPair value empty during the storeCachedDeviceList() if no exist, but found that smack omemoService does not in any point in the whole operation attempts to update the missing keyPair for the newly created identities entry. Neither OmemoService attempts to load the newly created keyPair.
/--------------------------------------/
Further testing shows that the olmMessage sent from aTalk (swan@atalk.org) contains only #2 but excluded #3 (alternate device); whereas olmMessage sent from conversations contains both #2 and #1 (alternate device).
swan@atalk.org:1711246335 (S3-aTalk)
leopard@atalk.org:1011347036 (Note3-aTalk)
swan@atalk.org:816614937 (S3-conversations)
=============== olmMessage sent from S3-aTalk to Note3-aTalk (leopard) ==================
07-24 14:17:12.277 D/SMACK: RECV (0): ****MwohBbNw++gXyOYvrwCqhlrN3SQu4GrGdcCUxr+OzNuOTxB1EAEYAyIw+tVlSC1SZokiODuMTAtBgkQF VujvkWcqbI9kCu5YVdxiZMInL3nN3YdswaX89uMNy5iMvTx5V3k=xwXPRDyyDz5oqJJ2Xr sJmw==niYQqw==I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo56de2403-0b80-4c24-ac16-95fe7a85018b
=============== olmMessage sent from S3-conversations to Note3-aTalk (leopard) ==================