Время загрузки Android с точностью до мкс

Время загрузки Android с точностью до мкс ⇐ Android

1 сообщение • Страница 1 из 1

Anonymous

Время загрузки Android с точностью до мкс

Цитата

Сообщение Anonymous » 25 янв 2025, 21:31

Это факт, что и время безотказной работы -s, и Kotlin:
object X {
private val startTime = Clock.System.now()
private val androidBootTime = startTime -
SystemClock.elapsedRealtime().toDuration(DurationUnit.MILLISECONDS)
< /code>
С x ссылается подкласс приложения,
возвращает точность, которая составляет около ± 10 секунд, т.е. Различные призывы создают разные времена загрузки для одного и того же сеанса загрузки 
Есть ли выбор кода Kotlin. Наибольшая достижимая точность времени загрузки Android? и преднамеренная медленя 
android boot uniquifiers < /h2>
29 октября 2024 г. Обновление: 
Существует счетчик Android 7 Android 7 + API Уровень 24+ 
int boot_count = Settings.Global.getInt(getContext().getContentResolver(),
Settings.Global.BOOT_COUNT);

есть uuid загрузочного сеанса:
cat /proc/sys/kernel/random/boot_id
c4dfb88f-2a9a-49cf-a649-291b4969db88

есть btime, секундная точность эпохи Unix:
cat /proc/stat | grep btime
btime 1729814103

При плохой загрузке Android с резервной батареей время может быть неправильным
видимо, читается uptime -s
cat /proc/uptime
408824.96 624814.45

чтобы между двумя показаниями часов можно было получить некоторую точность, например, взять среднее значение, округлить до ближайшей секунды или что-то в этом роде, если разница во времени меньше мс или около того.
Путь вперед — это приемник загрузки и периодическое чтение унификатора, первое расчетное значение времени загрузки, которое считается авторитетным. эмпирические данные для выбора метода
Проблемы с пользовательским интерфейсом
Пользовательский интерфейс Android также может перезапуститься. Я обнаружил две ситуации в logcat:

WATCHDOG уничтожает застрявший поток пользовательского интерфейса
DeadSystemException

Если в приложении есть фоновая служба с перезапуском, которая никогда не должна завершаться, это может быть обнаружено
может быть полезно передать logcat в потоковую передачу SD-карта емкостью 150 МБ, 1 М строк на каждую. день
Выводы 29 октября 2024 г.
Я буду использовать унификатор загрузки и первое рассчитанное время загрузки
Это все, что может сделать Android.
.
счетчик загрузки работает до сброса 1…
UUID загрузки работает
/proc/uptime так же плохо, как Android SystemClock.elapsedRealtime
/proc/stat не читается без прав root, но btime имеет точность до секунды (в реальном Android с хорошей батареей)
241105 для Android 12 2024 г.:

загрузка с неисправной резервной батареей может начаться с неточным временем
< ли>uptime -s и /proc/stat btime явно плохие
после исправления системного времени через NTP из Интернета оба значения меняются
поэтому, любая ссылка на время загрузки Android будет иметь погрешность в ±10 секунд из-за особенностей Android, даже если системное время очень точное. Полученное время может быть разным для разных попыток.
однако уникификаторы загрузки помогают различать события загрузки.
оценку времени загрузки нельзя получать до тех пор, пока системное время, как известно, является точным. Например, убедитесь, что точность времени Android превышает 2 минуты, подключившись к сайту https или обратившись к NTP PTP NITZ GPS.

Определение времени Android через NTP NITZ. Android 12 с 2024 г.:

осуществляется только каждые 18 часов.
исправляется только в том случае, если отклонение времени превышает 5 секунд.
если NTP не может быть прочитан в течение 3 минут, Android ждет еще 18 часов.
время можно попытаться обновить в рамках ограничений Android, выбрав «Настройки» — «Система» — «Дата и время» — «Установить время автоматически». с «Выкл.» на «Вкл.»

если недавний запрос NTP по каким-то причинам не удался, происходит ожидание 18 часов или установка времени вручную согласно конструкции тупых гуглеров
это не так можно принудительно обновить время, кроме «Настройки» — «Система» — «Дата и время».

необходимо подписать Google или системное приложение.

[*]Обратите внимание: если время отключено на 2 минуты и более, сертификаты не будут работать, так как в VPN может произойти сбой. В этом случае проверка подключения Android может завершиться неудачно, поэтому Android вообще не сможет подключиться к Интернету.

Android с неисправной резервной батареей может запуститься со временем, установленным на 1969 год.
Затем используется время сборки операционной системы, которое может быть 2022 годом или около того.
Это произойдет только после того, как временная метка будет получена из мобильной системы или Интернета. исправлено

Что действительно глупо со стороны гуглеров, так это ограничение в 5 секунд. В 2024 году должно быть 1 мс. Ничего не стоит

Воздействие — это воспринимаемая пользователем погрешность времени в ±5 секунд, которая совершенно не нужна. Вот почему Android не показывает секунды: это сокрытие документов Пентагона.
В результате любая временная метка, сообщаемая Android, составляет ±10 секунд.
Если разрешена ошибка времени более 100 мс, заметят ли пользователи, Google?

Утверждать, что это дерьмово, тупо и идиотично, — ничего не сказать. Это Google пытается сделать Android безопасным без плана.
Способ установки времени Android 1 декабря 2024 г.
Android получает время от главного компьютера, подключенного через adb

Точность времени можно проверить через Internet-ntp или gps-fix
Подключите устройство к adb , Настройки — Система — Дата и время — Установить время автоматически: Выкл. — Вкл.
Если неудачная попытка ntp не была предпринята в течение предшествующих 18 часов и при соблюдении других условий, указанных выше, время будет обновлено до времени хоста. Похоже, время Android adb имеет меньше ограничений по сравнению со временем ntp. Может быть, время всегда обновляется?
logcat покажет:

2024-12-01 06:55:37.715566 1000 1900 1945 D
AlarmManagerService: Setting time of day to sec=1733064917
2024-12-01 06:55:17.423629 1000 1900 1900 D
ConditionProviders.SCP: onReceive android.intent.action.TIME_SET
2024-12-01 06:55:17.423826 1000 1900 1900 D
ConditionProviders.SCP: evaluateSubscriptionLocked
cal=ScheduleCalendar[mDays={1, 2, 3, 4, 5, 6, 7},
mSchedule=ScheduleInfo{days=[1, 2, 3, 4, 5, 6, 7],
startHour=22, startMinute=0, endHour=7, endMinute=0,
exitAtAlarm=true,
nextAlarm=Wed Dec 31 16:00:00 PST 1969 (0)}],
now=Sun Dec 01 06:55:17 PST 2024 (1733064917423),
nextUserAlarmTime=Wed Dec 31 16:00:00 PST 1969 (0)
2024-12-01 06:55:17.433269 1000 1900 1957 I
UsageStatsService: User[0] Time changed in by -20 seconds
2024-12-01 06:55:17.548695 1000 1900 1957 I
UsageStatsDatabase: Time changed by -20s313ms. files deleted: 0 files moved: 19
2024-12-01 06:55:18.072561 10197 26701 26701 D
WM-RescheduleReceiver: Received intent Intent {
act=android.intent.action.TIME_SET flg=0x25200010
cmp=com.google.android.apps.messaging/
androidx.work.impl.background.systemalarm.RescheduleReceiver }
2024-12-01 06:55:18.090800 1000 1900 1957 I
UsageStatsService: Time changed in by -20 seconds
2024-12-01 06:55:19.499607 10144 3084 3206 W
UsageSyncManager: Last (TimeDelta{
wallTime=2024-11-30T19:32:34.447Z,
elapsedSinceBoot=PT52.836S},
boot count 30) and current (TimeDelta{
wallTime=2024-12-01T14:55:19.482Z,
elapsedSinceBoot=PT19H23M58.184S},
boot count 30) deltas are different.
Increase event shift by PT-20.313S.
< /code>
Чтобы проверить время устройства, на хосте macos do: 
date "+%F %T%z" && adb shell date -In
2024-12-01 07:38:26-0800
2024-12-01T07:38:26,172221743-08:00

или, поскольку macOS BSD не может работать с наносекундами:
python3 -c 'import datetime; print(datetime.datetime.now().astimezone())';
adb shell date -In
2024-12-01 08:05:00.108809-08:00
2024-12-01T08:05:00,252027835-08:00

Подробнее здесь: https://stackoverflow.com/questions/791 ... s-accuracy

1737829887

Anonymous

Это факт, что и время безотказной работы -s, и Kotlin:
object X {
private val startTime = Clock.System.now()
private val androidBootTime = startTime -
SystemClock.elapsedRealtime().toDuration(DurationUnit.MILLISECONDS)
< /code>
С x ссылается подкласс приложения,
возвращает точность, которая составляет около ± 10 секунд, т.е. Различные призывы создают разные времена загрузки для одного и того же сеанса загрузки < /p>
 Есть ли выбор кода Kotlin. Наибольшая достижимая точность времени загрузки Android? и преднамеренная медленя < /p>
 android boot uniquifiers < /h2>
29 октября 2024 г. Обновление: < /p>
Существует счетчик Android 7 Android 7 + API Уровень 24+ < /p>
int boot_count = Settings.Global.getInt(getContext().getContentResolver(),
Settings.Global.BOOT_COUNT);

есть uuid загрузочного сеанса:
cat /proc/sys/kernel/random/boot_id
c4dfb88f-2a9a-49cf-a649-291b4969db88

есть btime, секундная точность эпохи Unix:
cat /proc/stat | grep btime
btime 1729814103

При плохой загрузке Android с резервной батареей время может быть неправильным
видимо, читается uptime -s
cat /proc/uptime
408824.96 624814.45

чтобы между двумя показаниями часов можно было получить некоторую точность, например, взять среднее значение, округлить до ближайшей секунды или что-то в этом роде, если разница во времени меньше мс или около того.
Путь вперед — это приемник загрузки и периодическое чтение унификатора, первое расчетное значение времени загрузки, которое считается авторитетным. эмпирические данные для выбора метода
Проблемы с пользовательским интерфейсом
Пользовательский интерфейс Android также может перезапуститься. Я обнаружил две ситуации в logcat:
[list]
[*]WATCHDOG уничтожает застрявший поток пользовательского интерфейса
[*]DeadSystemException
[/list]
Если в приложении есть фоновая служба с перезапуском, которая никогда не должна завершаться, это может быть обнаружено
может быть полезно передать logcat в потоковую передачу SD-карта емкостью 150 МБ, 1 М строк на каждую. день
Выводы 29 октября 2024 г.
Я буду использовать унификатор загрузки и первое рассчитанное время загрузки
Это все, что может сделать Android.
.
счетчик загрузки работает до сброса 1…
UUID загрузки работает 
/proc/uptime так же плохо, как Android SystemClock.elapsedRealtime
/proc/stat не читается без прав root, но btime имеет точность до секунды (в реальном Android с хорошей батареей)
241105 для Android 12 2024 г.:
[list]
[*]загрузка с неисправной резервной батареей может начаться с неточным временем
< ли>uptime -s и /proc/stat btime явно плохие
[*]после исправления системного времени через NTP из Интернета оба значения меняются
[*]поэтому, любая ссылка на время загрузки Android будет иметь погрешность в ±10 секунд из-за особенностей Android, даже если системное время очень точное. Полученное время может быть разным для разных попыток.
[*]однако уникификаторы загрузки помогают различать события загрузки.
[*]оценку времени загрузки нельзя получать до тех пор, пока системное время, как известно, является точным. Например, убедитесь, что точность времени Android превышает 2 минуты, подключившись к сайту https или обратившись к NTP PTP NITZ GPS.
[/list]
Определение времени Android через NTP NITZ. Android 12 с 2024 г.:
[list]
[*]осуществляется только каждые 18 часов.
[*]исправляется только в том случае, если отклонение времени превышает 5 секунд.
[*]если NTP не может быть прочитан в течение 3 минут, Android ждет еще 18 часов.
[*]время можно попытаться обновить в рамках ограничений Android, выбрав «Настройки» — «Система» — «Дата и время» — «Установить время автоматически». с «Выкл.» на «Вкл.»

если недавний запрос NTP по каким-то причинам не удался, происходит ожидание 18 часов или установка времени вручную согласно конструкции тупых гуглеров


[*]это не так можно принудительно обновить время, кроме «Настройки» — «Система» — «Дата и время».

необходимо подписать Google или системное приложение.
[/list]

[*]Обратите внимание: если время отключено на 2 минуты и более, сертификаты не будут работать, так как в VPN может произойти сбой.  В этом случае проверка подключения Android может завершиться неудачно, поэтому Android вообще не сможет подключиться к Интернету.
[list]
Android с неисправной резервной батареей может запуститься со временем, установленным на 1969 год.
[*]Затем используется время сборки операционной системы, которое может быть 2022 годом или около того.
[*]Это произойдет только после того, как временная метка будет получена из мобильной системы или Интернета. исправлено
[/list]


Что действительно глупо со стороны гуглеров, так это ограничение в 5 секунд. В 2024 году должно быть 1 мс. Ничего не стоит
[list]
[*]Воздействие — это воспринимаемая пользователем погрешность времени в ±5 секунд, которая совершенно не нужна. Вот почему Android не показывает секунды: это сокрытие документов Пентагона.
[*]В результате любая временная метка, сообщаемая Android, составляет ±10 секунд.
[*]Если разрешена ошибка времени более 100 мс, заметят ли пользователи, Google?
[/list]
Утверждать, что это дерьмово, тупо и идиотично, — ничего не сказать. Это Google пытается сделать Android безопасным без плана.
Способ установки времени Android 1 декабря 2024 г.
Android получает время от главного компьютера, подключенного через adb
[list]
[*]Точность времени можно проверить через Internet-ntp или gps-fix
[*]Подключите устройство к adb , Настройки — Система — Дата и время — Установить время автоматически: Выкл. — Вкл.
[*]Если неудачная попытка ntp не была предпринята в течение предшествующих 18 часов и при соблюдении других условий, указанных выше, время будет обновлено до времени хоста. Похоже, время Android adb имеет меньше ограничений по сравнению со временем ntp. Может быть, время всегда обновляется?
[*]logcat покажет:
[/list]
2024-12-01 06:55:37.715566  1000  1900  1945 D
AlarmManagerService: Setting time of day to sec=1733064917
2024-12-01 06:55:17.423629  1000  1900  1900 D
ConditionProviders.SCP: onReceive android.intent.action.TIME_SET
2024-12-01 06:55:17.423826  1000  1900  1900 D
ConditionProviders.SCP: evaluateSubscriptionLocked
cal=ScheduleCalendar[mDays={1, 2, 3, 4, 5, 6, 7},
mSchedule=ScheduleInfo{days=[1, 2, 3, 4, 5, 6, 7],
startHour=22, startMinute=0, endHour=7, endMinute=0,
exitAtAlarm=true,
nextAlarm=Wed Dec 31 16:00:00 PST 1969 (0)}],
now=Sun Dec 01 06:55:17 PST 2024 (1733064917423),
nextUserAlarmTime=Wed Dec 31 16:00:00 PST 1969 (0)
2024-12-01 06:55:17.433269  1000  1900  1957 I
UsageStatsService: User[0] Time changed in by -20 seconds
2024-12-01 06:55:17.548695  1000  1900  1957 I
UsageStatsDatabase: Time changed by -20s313ms. files deleted: 0 files moved: 19
2024-12-01 06:55:18.072561 10197 26701 26701 D
WM-RescheduleReceiver: Received intent Intent {
act=android.intent.action.TIME_SET flg=0x25200010
cmp=com.google.android.apps.messaging/
androidx.work.impl.background.systemalarm.RescheduleReceiver }
2024-12-01 06:55:18.090800  1000  1900  1957 I
UsageStatsService: Time changed in by -20 seconds
2024-12-01 06:55:19.499607 10144  3084  3206 W
UsageSyncManager:  Last (TimeDelta{
wallTime=2024-11-30T19:32:34.447Z,
elapsedSinceBoot=PT52.836S},
boot count 30) and current (TimeDelta{
wallTime=2024-12-01T14:55:19.482Z,
elapsedSinceBoot=PT19H23M58.184S},
boot count 30) deltas are different.
Increase event shift by PT-20.313S.
< /code>
Чтобы проверить время устройства, на хосте macos do: < /p>
date "+%F %T%z" && adb shell date -In
2024-12-01 07:38:26-0800
2024-12-01T07:38:26,172221743-08:00

или, поскольку macOS BSD не может работать с наносекундами:
python3 -c 'import datetime; print(datetime.datetime.now().astimezone())';
adb shell date -In
2024-12-01 08:05:00.108809-08:00
2024-12-01T08:05:00,252027835-08:00
 

Подробнее здесь: [url]https://stackoverflow.com/questions/79129321/android-boot-time-with-%ce%bcs-accuracy[/url]