Einstellungen Zeitdifferenz von System.currentTimeMillis()

Question

fand ich, was nicht in Ordnung war:

So scheinbar http://www.epochconverter.com/ ist, macht Annahmen der Genauigkeit der Eingangswerte, und von diesen Annahmen Werten um 841073068 geht zu 1996/1997 . Ich bin mir nicht sicher, was die Annahme ist, die zu genau diesem Datum führt, aber ehrlich gesagt interessiert mich das nicht.

Mit dem angehängten Debugger rief ich new Date(System.currentTimeMillis()) und es gab mir richtig ein 10. Jan-1070 Datum, was bedeutet, dass die Uhr nicht wie verrückt aus dem Weg springen.

Original Frage:

Ich bin ein Single-Board-Computer mit Android läuft für und IoT Fall (dies https://developer.qualcomm.com/hardware/dragonboard-410c). Das laufende Betriebssystem ist das Plain-Vanilla-Android von Qualcomm.

Momentan teste ich die Zuverlässigkeit des Boards, dass es für lange Zeit auf einmal ausgeführt wird und ich sehe ein sehr, sehr seltsames Verhalten, für das ich keine Erklärung finden kann.

Die Karte wurde vor 10 Tagen eingeschaltet und hat keinen Zugang zum Internet (WiFi ist eingeschaltet, aber kein Access Point Setup und kein Ethernet). Das Bluetooth ist an und es gibt iBeacons und Eddystone im Büro. Auch gibt es WiFi in der Gegend.

Wenn ich jetzt gehe zu Settings -> Date and Time, oder überprüfen Sie die Benachrichtigung Schatten oder geben Sie die Uhr App oder die Kalender-App, sehe ich 10. Januar 1970. Welche erwartet wird und grundsätzlich für wie lange das Board ausgeführt wurde.

Die App darauf haben einen immer laufenden Dienst, der einige Datenverarbeitung und einige Disk-Logging (zum Debuggen).

Aus den Protokollen kann ich sehen, dass System.currentTimeMillis() einen erwarteten Wert zurückgegeben hat, als die Platine zum ersten Mal eingeschaltet wurde. Das heißt, der Anfang der Protokolle zeigt eine Epoche im Januar 1970.

Aber am Ende der Protokolle (und auch den Debugger im Live-Prozess anhängen), ist der Wert von System.currentTimeMillis() irgendwo im September/Oktober 1996 . Beispielwerte: 841073068, 841263234, 841579239

Also meine Frage ist:

• Was hier geschieht?
• Warum System.currentTimeMillis() Wert geändert und was könnte es geändert haben?
• Warum zeigt mir die Android-Benutzeroberfläche (Benachrichtigung, Uhr-App, Einstellungen) noch 1970? Woher bekommen sie diesen Wert?

edit:

Es gab einige Verwirrung auf den Antworten, und ich kann meine Frage fehlte die Details sehen.

Ich möchte nicht den Unterschied der Zeit messen. Ich brauche einen aktuellen Zeitstempel. Diese Werte werden mit Bluetooth LE-Ereignissen über POST an unser Backend gemeldet.Dieses "No Network" -Ding ist ein Zuverlässigkeitstest, den wir auf dem Board ausführen, aber wir erwarten, dass wir die meiste Zeit über ein Netzwerk haben, und die Boards sollten ihre Zeiten automatisch vom Netzwerk auf die normale Android-Art aktualisieren.

Ich versuche nur zu verstehen, auf der aktuellen Charge von Tests, was schief gelaufen ist und warum.

Answer 1

Nun, wie Sie bereits wissen, die aktuelle Systemzeit (System.currentTimeMillis()) kann von jedem Prozess geändert werden, wenn es gewünscht wird, ist es durchaus möglich, dass es von einem anderen Prozess geändert wurde. Es ist keine zuverlässige Methode zur Messung der Betriebszeit.

Ich würde rater verwenden so etwas wie:

SystemClock.uptimeMillis() 

Welche returns die verstrichene Zeit (in Millisekunden), da das Gerät gebootet (keine Zeit, auch in Tiefschlaf verbrachte).

Ich möchte auch erwähnen, dass ich vermute, dass Bluetooth etwas damit zu tun hat, kann ich mir vorstellen, dass Bluetooth die Systemzeit für die Paarung und Sicherheit genauso wie SSL verwendet (aber ich bin kein Experte). GPS kann auch ein Problem sein, da GPS verwendet werden kann, um einen UTC-Zeitwert zu erhalten, aber ich bin mir nicht sicher, ob Ihr Board über ein GPS-Modul verfügt.

In Bezug auf Ihre edit:

einen gültigen Zeitstempel Beschaffung wäre ganz einfach: Serverzeit minus der von dem Board berichtet verstrichene Zeit. Aber ich schlage vor, dass Sie entweder die von System.currentTimeMillis() berichtete Zeit akzeptieren oder stattdessen die verstrichene Zeit verwenden. In der Firma, in der ich arbeite, arbeiten wir auch mit eingebetteten Android-Geräten und auf unserem Server-Dashboard können wir sowohl die Up-Time (seit seit) als auch die aktuelle Gerätezeit sehen, aber sie sollten zumindest meiner Meinung nach nicht gemischt werden, besonders seit System.currentTimeMillis() unterliegt Änderungen und ist von Sommer- und Winterzeit betroffen.

Answer 2

Wenn Sie etwas messen möchten, versuchen Sie besser System.nanoTime(). Hier ist der Unterschied - https://stackoverflow.com/a/351571/2793494