getCurrentTimeMs() return the wrong date time everytime I manually change the device clock about kronos-android HOT 10 OPEN

I am also experiencing strange behavior with this testing flow. kronos will have a valid NTP time and return it to me. When I minimize and manually set phone time, and return to my app, kronos appears to have cleared the NTP time offsets for some reason, and now I am being returned the incorrect phone time.

I expected the whole point of this library was to maintain the offset between RTC clock and NTP time and thus still be able to give me NTP time.

from kronos-android.

I think the problem is related to the way that kronos-android detects whether the system has been rebooted.

The library uses deviceElapsedTimestampMs from SystemClock in android as the source of local time.
However, this value will be reset when the system is booted. So library needs to know whether the system has been rebooted since it got NTP time from the servers.

To detect the reboot, library uses difference between deviceCurrentTimeMillis and deviceElapsedTime. If the diff has changed significantly, it assumes that the device is rebooted. So if you change the device clock and open the app, the diff will change and library thinks that the device is rebooted and throw away the cache. (Which is ok since most users don't change the system clock & even when they do, kronos will try to synchronize and eventually get the NTP time)

I cannot think of other way of detecting boot without changing the Clock interface in kronos.
I think using Settings.Global#BOOT_COUNT will fix this problem.

from kronos-android.

Im actually now running into this as well. The system time is returned immediately after updating the date manually. It the resets after a sync

from kronos-android.

Guys, if it helps: My app is running for a while with the workaround that I suggested in my previous comment (call kronosClock.syncInBackground(); when the app goes to foreground), I don't think is a definitive solution, but works and looks like is what we have for now.

from kronos-android.

Yes, that's why I don't think this is a definitive solution, is just a workaround that reduces this issue impact.

from kronos-android.

I don't think it works since we're testing scenarios where there's no internet and syncInBackground would fail.

The scenario we're trying to work for:

1. Phone has internet, app is launched, kronos syncs with server and gets time.
2. User turns off internet on phone (and mobile data)
3. User manually changes phone time to something else. Phone is NOT rebooted

Expectation:
Kronos still knows and returns NTP time, since it should have an offset of RTC clock to Server time that is valid.

Reality:
Kronos does not know or return NTP time since it for some reason flushed the caches.

from kronos-android.

Maybe @keith @arturdryomov or someone else at Lyft team could guide us into a definitive solution.

from kronos-android.

@Rajin9601 That's a good find.

I don't think I agree that it's a correct behavior. We have an additional tool available to us to know if the phone was rebooted vs the time being altered manually by the user. Basically, it's the runtime (or the existence of memory).

If the realtime clock to currentTimeMillis offset (or difference) is changed or invalidated, but the library still exists in memory or runtime (I mean the app is still running), then we know the device wasn't rebooted. Since we know this, we know that the offset between realtime clock and NTP time is still valid, and thus we can still have a good state of "NTP time certainty".

Now if the app running the kronos library is killed, and then the user changes phone time, well, we're out of luck. THere's no way to distinguish if the phone rebooted from user phone time.

I guess I'm wondering why the library doesn't simply just rely on the offset maintained in memory? It seems to be clearing it's memory when the realtime and currentTimeMIllis offsets are invalidated, and that's unnecessary.

from kronos-android.

Although if your PR works well and gets approval, my suggestion is redundant.

from kronos-android.

@jh0719 I think your suggestion (checking the reboot when getting the offset from the device cache, not when getting it from the memory) can also work.

Meanwhile, you can use broadcast receiver and re-sync in background when user changes the time. (code from the demo app)

from kronos-android.