2016-03-28 93 views
2

我一直在使用wifiManager.startScan();從附近的Wi-Fi接入點接收數據。這將作爲ScanResult列表返回。這個類可以在這裏找到: http://developer.android.com/reference/android/net/wifi/ScanResult.html#timestampAndroid ScanResult時間戳字段 - 它有多準確?

我明白ScanResult的時間戳字段是微秒

時間戳(自啓動)當這個結果最後 看到。

所以我用一些計算來獲得當接入點被智能手機設備看到的實際時間戳:

long actualTimestamp = System.currentTimeMillis() - SystemClock.elapsedRealtime() + (scanResult.timestamp/1000); 

這工作得很好,但我有一些罕見有趣的結果:

15時04分01秒28-03-2016 - 1459173841

22點五十分44秒2016年7月6日 - 146533624 4

15時04分21秒28-03-2016 - 1459173861

2016年6月條目上述通知,其被放置在其他的讀數之間在將來的日期從所述列表內聚集。

這裏可能會發生什麼?我的代碼有點不對嗎?時間戳值偶爾不準確?有誰之前經歷過這個嗎?

編輯:我正在Nexus 5棉花糖設備上進行測試。 MinSDK 18,Target 23

+0

我得到的一些結果我也不相信。我嘗試過濾比X ms更早的結果,但是我非常肯定,包含scanresults的列表中的結果不應該存在,或者它包含不正確的信號強度(我的應用程序試圖找到最佳接入點並且它在我開始走向另一個之前,一直選擇AP是*最好的),這導致我相信信號電平和時間戳不對應。 – REJH

+0

想想吧..也許在AOSP bug跟蹤器上創建一個關於這個的問題? – REJH

+0

@REJH自從這篇文章,我能夠主要通過移動(步行,駕駛等)在一部手機上覆制這個問題。時間戳將在未來結束。在不同的設備上,時間戳會保留在結果中,永遠不會被刪除,這意味着它將始終過時。假設我們不能相信所有結果是安全的 - 但我們可以將它們濾除。在開始掃描時記錄,並在結束時記錄,然後僅選擇該時間範圍內的結果。 – Jonty800

回答

1

我似乎有一個解釋:這是一個錯誤。

我偶爾會看到.timestamp(自重新啓動後的微秒)將等於.seen(自Epoch以來的秒數)。如今,如果重新解釋爲微秒時間段,則時間大約爲17天。

由於2個值顯然不可能是平等的,我也提交到Android: https://code.google.com/p/android/issues/detail?id=225218 隨意標註星號:)