我有一个应用程序，它使用基于udp的自定义协议与嵌入式设备通信。为了验证设备仍在网络上，我将数据报套接字的接收端设置为1秒超时。如果超时触发，我会向嵌入式设备发送回显请求，然后等待一秒钟（如果发生两次，我认为无法进行进一步的通信，并将应用程序的内部状态更改为断开连接）。
在测试应用程序时，注意到该应用程序会突然切换到断开状态（这可能会发生5分钟到2.5小时的运行时间）。嵌入式设备上未发生任何错误，并且tcpdump显示嵌入式设备在30毫秒内响应。 tcpdump还显示了最终的回声请求集全部在10ms内发送到了服务器。
wireshark display of tcpdump data
我不知道系统时钟在时间上突然跳跃的可能性有多大，但这就是看起来正在发生的情况。
哦，这已经在以下设备上进行了测试：
该问题仅被记录为在“ Galaxy”标签上发生
有没有其他人注意到此设备或其他设备的计时问题，因此事件会在较早触发？具体来说，系统时钟将在哪里报告已过去的时间超过实际的时间？如果是这样，关于如何减轻这种情况的任何建议？如果不是，没有人知道导致这些症状的其他原因吗？
使用SystemClock.elaspedRealtime()和SystemClock.uptimeMillis()来自udp侦听器的时间日志：
pre recieve: elapsedRealtime: 191128173 uptimemillis: 106498062
pre recieve: elapsedRealtime: 191129199 uptimemillis: 106499088
pre recieve: elapsedRealtime: 191130224 uptimemillis: 106500113
pre recieve: elapsedRealtime: 191131252 uptimemillis: 106501141
pre recieve: elapsedRealtime: 191132278 uptimemillis: 106502167
pre recieve: elapsedRealtime: 191133301 uptimemillis: 106503190
pre recieve: elapsedRealtime: 191134325 uptimemillis: 106504214
pre recieve: elapsedRealtime: 191135350 uptimemillis: 106505239
pre recieve: elapsedRealtime: 191136376 uptimemillis: 106506265
pre recieve: elapsedRealtime: 191137400 uptimemillis: 106507289
post timeout: elapsedRealtime: 191138404 uptimemillis: 106508293
pre recieve: elapsedRealtime: 191138406 uptimemillis: 106508295
post timeout: elapsedRealtime: 191139409 uptimemillis: 106509298