Settings Разница во времени с System.currentTimeMillis()

Question

Я нашел то, что было не так:

Таким образом, очевидно http://www.epochconverter.com/ это делает предположения о точности входных значений, и из этих предположений значения вокруг 841073068 идет в 1996/1997 , Я не уверен, что такое предположение, которое ведет к этой точной дате, но, честно говоря, мне все равно.

Используя прилагаемый отладчик, я позвонил new Date(System.currentTimeMillis()), и он правильно дал мне дату 10-го января-1070 года, то есть часы не выпрыгивают из пути, как сумасшедшие.

Оригинальный вопрос:

Я бегу одноплатный компьютер с Android для и случай IoT (это https://developer.qualcomm.com/hardware/dragonboard-410c). Операционная система - это простой ванильный Android от Qualcomm.

В настоящее время я проверяю надежность платы, которая будет выполняться в течение длительных периодов времени, и я вижу очень странное поведение, и я не могу найти объяснения.

Совет был включен 10 дней назад, и у него нет доступа к Интернету (WiFi включен, но нет точки доступа и нет Ethernet). Bluetooth включен, и в офисе есть iBeacons и Eddystone. Также в этом районе есть WiFi.

Если я перейду сейчас к Settings -> Date and Time, или проверьте оттенок уведомления или войдите в приложение часов или приложение для календаря, я вижу 10 января 1970 года. Ожидается и в основном показывается, как долго работает панель.

Приложение на нем имеет всегда запущенную службу, которая выполняет некоторую обработку данных и некоторую регистрацию на диске (для отладки).

Из журналов я вижу, что System.currentTimeMillis() возвращал ожидаемое значение, когда плата была изначально включена. Это означает, что начало журналов указывает на эпоху в январе 1970 года.

Но в конце журналов (а также прикрепления отладчика в реальном времени) значение System.currentTimeMillis() находится где-то в сентябре/октябре 1996 года . Пример значения: 841073068, 841263234, 841579239

Так что мой вопрос:

• Что здесь происходит?
• Почему значение System.currentTimeMillis() изменилось и что изменилось?
• Почему Android UI (уведомление, приложение часов, настройки) все еще показывает мне 1970? Откуда они получают эту ценность?

редактировать:

Там было некоторое замешательство на ответы, и я вижу, что мой вопрос не хватает деталей.

Я не хочу измерять разницу во времени. Мне нужна фактическая отметка времени. Эти значения будут сообщаться с событиями bluetooth LE через POST на наш сервер.Эта «не сетевая» вещь - это тест надежности, который мы используем на плате, но мы ожидаем большую часть времени использовать сеть, и платы должны автоматически обновлять свое время из сети, используя обычные способы Android.

Я просто пытаюсь понять текущую последовательность тестирования, что пошло не так и почему.

Answer 1

Ну, как вы уже знаете, текущее системное время (System.currentTimeMillis()) может быть изменено любым процессом при желании, вполне возможно, что он был изменен другим процессом. Это не надежный метод измерения времени.

Я бы оценщику использовать что-то вроде:

SystemClock.uptimeMillis() 

Каких returns истекшего время (в миллисекундах), так как устройство загрузится (не включая время, проведенное в глубоком сне).

Я также хотел бы упомянуть, что я подозреваю, что Bluetooth имеет к этому какое-то отношение, я могу себе представить, что Bluetooth использует системное время для сопряжения и безопасности, как это делает SSL (но я не эксперт). GPS также может быть проблемой, поскольку GPS можно использовать для получения значения времени UTC, но я не уверен, что на вашем борту есть модуль GPS.

Что касается вашего редактирования:

Получения действительного времени штампа будет довольно легко: по времени сервера минус прошедшего время сообщенного по доске. Но я предлагаю вам либо выбрать время, указанное System.currentTimeMillis(), либо вместо этого использовать прошедшее время. В компании, которую я работаю, мы также работаем со встроенными устройствами Android, и на нашей информационной панели сервера мы можем видеть как время работы (вверх с), так и текущее время устройства, но они не должны смешиваться, по крайней мере, на мой взгляд, тем более, что System.currentTimeMillis() может быть изменен и зависит от летнего и зимнего времени.

Answer 2

Если вы хотите что-то измерить, лучше попробуйте System.nanoTime(). Вот разница - https://stackoverflow.com/a/351571/2793494