I now have a better understanding what is the actual cause of my observation. Please refer to my discussion on
Smack Omemo Identities Regenerate failed on slow android device due to reply timeout
I believe there are two folds to the problem.
1a. From the test observation, I believe the Smack/OmemoManager starts the reply timeout timer immediately after it has triggered the process to send Omemo prekeys. So the timer starts to count down while the generation of prekey is still in progress (async). On a slow device or device with AOT disabled, it takes almost 3 minutes to generate the prekeys before the actual prekey bundles are sent to the server.
1b. In order to resolve this problem, the smack must ensure the stanza reply timer is sync to the actual stanza sending i.e. the reply timer count down should only start after the stanza has been sent. Otherwise reduces the prekeys bundle to 30 will not eliminate this problem.
FYI: Actually I also faced similar problem on S3 during login process due to challenge sasl reply generation. I have to increase the reply timer to 50 seconds to get S3 to work.
1c. Even with the above problem resolved, a slow device like S3, the time taken from prekeys bundle sending and server reply is about 7 seconds for 100 prekeys bundle, I propose OmemoManager to set the reply timeout to 10 seconds to take care of some slow device or heavily loaded server during prekey bundle sending process.
aTalk currently sets the timer to 10-second globally, as I cannot find a reliable way to know prior to omemoManager prekey sending.
2a. The second problem is pending whether the android device is running with Dalvik (prior KitKat 4.4) or ART.
On Android KitKat 4.4, android introduces the ART (AOT) versus the old Dalvik (JIT). When I disable ART on my Note 3, it immediately failed the reply timeout on first apk installation/launch as it deploys the JIT approach.
2b. Even on Note 3 with ART, it takes about 4 seconds turn around time for prekeys sending and reply from server. So the current default 5 seconds may be a bit tight on a busy server.
2c. From observation, I can see that on the subsequent launching of aTalk, it is faster. Look like android device performs some cache of the earlier JIT compiled byte code even on S3.
With 1b implemented and a 10-second smack reply timer, it should resolve the problem.
Note. the stanza reply timeout also happen on other stanza iq sending even with the reply is received within 100mS. I am not sure what is the root cause of this problem. Look like some smack processes are holding the cpu resource; I see the iq reply checking is by polling.