Return to Revisions

It is a fact that both uptime -s and Kotlin:

object X {
 private val startTime = Clock.System.now()
 private val androidBootTime = startTime - SystemClock.elapsedRealtime().toDuration(DurationUnit.MILLISECONDS)

with X referenced by an Application subclass, returns an accuracy that is around ±10 seconds, ie. different invocations produce different boot times for the same boot session

Is there a Kotlin code-sample producing μs-accuracy boot time?

What is the highest attainable accuracy of Android boot time?

It is also a fact that determining the start time of your app can only be done by a static timestamp, all other intelligent means are defeated by Android caching and intentional slowness

Android boot uniqifiers

October 29 2024 update:

there is boot counter Android 7+ api level 24+

int boot_count = Settings.Global.getInt(getContext().getContentResolver(),
 Settings.Global.BOOT_COUNT);

there is boot session uuid:

cat /proc/sys/kernel/random/boot_id 
c4dfb88f-2a9a-49cf-a649-291b4969db88

there is btime, unix epoch second precision:

cat /proc/stat | grep btime
btime 1729814103

When a poor backup-battery Android boots up, time may be incorrect

apparently uptime -s reads

cat /proc/uptime 
408824.96 624814.45

so this in between two clock reads can obtain some kind of precision, like take average, round to nearest second or such if time difference is less than ms or so

The way forward is boot receiver and periodic uniqifier reads, the first estimated boot time value considered authoritative. empiric evidence to select method

UI issues

Android UI may restart, too. I have found two situations in logcat:

1. WATCHDOG kills a deadlocked UI thread
2. DeadSystemException

If an app has a background service with restart that should never exit, this may be detected

it might be helpful to stream logcat to sd card which is 150 MiB 1M lines per day

Coclusions October 29 22024

I will use a boot uniqifier and the first calculated boot time

That’s all Android can do.

.

boot counter works until reset 1...

boot UUID works

/proc/uptime is as bad as Android SystemClock.elapsedRealtime

/proc/stat is not readable without root permission but btime is accurate to the second (in a good battery real Android)

241105 for 2024 Android 12:

• boot with bad back-up battery may start with inaccurate time
• uptime -s and /proc/stat btime are obviously bad
• after correcting system time via NTP from the Internet, both values change
• therefore, any reference to Android boot time will suffer from an inaccuracy of ±10 seconds due to Android idiosyncrasies even when system time is highly accurate. The produced time may be different for different attempts
• however, the boot uniquifiers work to distinguish boot events
• the boot time estimate should not be acquired until system time is known to be accurate. For example, verify Android time accuracy to be better than 2 minutes by connecting to an https site or consulting NTP PTP NITZ GPS

Android time detection via NTP NITZ as of 2024 Android 12:

• is only attempted every 18 hours
• only corrects if time deviation more than 5 seconds
• if NTP cannot be read within 3 minutes, Android waits another 18 hours
• can be attempted within Android limitations by Settings — System — Date & time — Set time automatically to Off to On
  • if a recent NTP request somehow failed, it’s wait 18 hours or set time manually per the dumb Googlers’ design
• it is not possible to force a time update other than Settings — System — Date & time
  • need to be signed by Google or system app
• Note that if time is off 2 minutes or more, certificates will not work as in VPN may fail. Android connectivity check may then fail, so Android cannot connect to the Internet at all

What is really dumb by them Googlers is the 5 seconds allowance. In 2024. Should be 1 ms. Costs nothing

To claim that this is shitty and dumb and idiotic is an understatement. It’s Google trying to make Android safe without a plan