Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DiskCacheClient.isTrueTimeCachedFromAPreviousBoot boot time change check flaw #124

Open
breautek opened this issue Nov 19, 2019 · 1 comment

Comments

@breautek
Copy link

boolean isTrueTimeCachedFromAPreviousBoot() {
if (cacheUnavailable()) {
return false;
}
long cachedBootTime = _cacheInterface.get(KEY_CACHED_BOOT_TIME, 0L);
if (cachedBootTime == 0) {
return false;
}
// has boot time changed (simple check)
boolean bootTimeChanged = SystemClock.elapsedRealtime() < getCachedDeviceUptime();
TrueLog.i(TAG, "---- boot time changed " + bootTimeChanged);
return !bootTimeChanged;
}

This method has a serious flaw. I'll start by providing a sequence of action scenario, Base and Scenario A, and finally Scenario B

Base

Phone boots
App launches
requestTime is fired and the deviceUptime is cached at 10 seconds (easy round numbers for simplicity)
cachedDeviceUptime = 10

Scenario A

Assuming the events of Base occurred first, imagine the following actions

Phone reboot
5 seconds later app is launched and truetime is initialize()
cachedDeviceUptime is still 10.
elapsedTime is 5

5 < 10 is true thus isTrueTimeCachedFromAPreviousBoot returns false, thus truetime is not initialized as expected.

Scenario B

This scenario exposes the flaw. Let's assume that the previous actions came from Base (Ignore Scenario A)

Phone reboots
20 seconds later app is launched and truetime is initialize()
cachedDeviceUptime is 10.
elapsedTime is 20

20 < 10 is false thus isTrueTimeCachedFromAPreviousBoot returns true, thus truetime is initialized using old and stale cached data.

This does relate to #85 somewhat. This is mostly an issue if the boot receiver for some reason does not broadcast the boot event to the application (say if the application is in a stopped state after a force-close).

@Tgo1014
Copy link

Tgo1014 commented Jun 13, 2022

No solution for this yet? I'm having this issue and apparently creating a custom cache with the solution from #93 is the only solution, but would be nice to have a fix merged on the lib

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants