When SystemClock.SetCurrentTimeMillis() is executed the Environment.Tickcount is also changed.
Also when you then restart the app the Environment.TickCount seems to revert back to the correct value.
This did not use to happen, it has been introduced in the last 12 months or so, I am not sure the exact version this bug was introduced.
If you execute these lines it shows the issue
Log.Info("TickCount", "Before:" + Environment.TickCount);
var jan1St1970 = new DateTime(1970, 1, 1, 0, 0, 0);
var newTime = DateTime.UtcNow.AddHours(1);
SystemClock.SetCurrentTimeMillis((long)(newTime - jan1St1970).TotalMilliseconds);
Log.Info("TickCount", "After:" + Environment.TickCount);
which produces the following output
07-28 14:27:52.359: I/TickCount(5900): Before:2664268
07-28 14:27:52.379: D/Mono(5900): DllImport searching in: '__Internal' ('(null)').
07-28 14:27:52.379: D/Mono(5900): Searching for 'java_interop_jnienv_call_static_boolean_method_a'.
07-28 14:27:52.379: D/Mono(5900): Probing 'java_interop_jnienv_call_static_boolean_method_a'.
07-28 14:27:52.379: D/Mono(5900): Found as 'java_interop_jnienv_call_static_boolean_method_a'.
07-28 14:27:52.379: D/(5900): Setting time of day to sec=1501266472
07-28 15:27:52.374: V/AlarmManager(2790): Time changed notification from kernel; rebatching
07-28 15:27:52.374: I/TickCount(5900): After:6264285
Are you trying this on a rooted phone or elevated privileges? Given the `SET_TIME` permission is signatureOrSystem, it can only be used in apps that are signed with the system image or installed in the /system/ folder. Otherwise you'll get the following exception:
07-26 09:14:13.515 E/SystemClock(10450): Unable to set RTC
07-26 09:14:13.515 E/SystemClock(10450): java.lang.SecurityException: setTime: Neither user 10274 nor current process has android.permission.SET_TIME.
I'd like to gather some more information on your end such as:
1) Your current Xamarin information. https://developer.xamarin.com/guides/cross-platform/troubleshooting/questions/version-logs/
2) The expected behavior vs. the actual behavior
3) Reproduction steps for running your code given the `SET_TIME` limitation mentioned earlier
Thank you for the report!
Ah yes you do need to have the permission.
Our app is system signed.
I just checked a simpler way which also shows the issue without system signing.
I created an app which just prints the Environment.Tickcount value every 3 seconds.
Then with the app running I open the android settings and change the time manually, advancing by a few hours and noticing the TickCount is changed in the android log.
I just start a thread that uses this function
private void DoTime()
Log.Info("TickCount", "Time:" + Environment.TickCount);
this gives the following result in the android log
07-26 01:39:31.140: I/TickCount(24433): Time:66443406
07-26 01:39:34.140: I/TickCount(24433): Time:66446409
07-26 01:39:37.145: I/TickCount(24433): Time:66449411
07-26 01:39:40.150: I/TickCount(24433): Time:66452414
07-26 01:39:43.150: I/TickCount(24433): Time:66455415
07-26 01:39:46.150: I/TickCount(24433): Time:66458418
07-26 01:39:49.155: I/TickCount(24433): Time:66461420
07-26 02:39:00.410: I/TickCount(24433): Time:70012677
07-26 02:39:03.410: I/TickCount(24433): Time:70015678
07-26 02:39:06.410: I/TickCount(24433): Time:70018680
07-26 02:39:09.415: I/TickCount(24433): Time:70021682
07-26 02:39:12.415: I/TickCount(24433): Time:70024684
you can see the big jump from 66461420 to 70012677
this should not occur it should have been about 66464420
Then when I restart the app, the TickCount reverts to the correct value, with the big offset disappearing and the correct value being returned.
I will take a look now at the extra logs you want me to send you but this one should now be very simple to reproduce on your end.
I will attach the sample app, it is just a empty opengl app with this one thread added to output the time to the log.
Created attachment 23822 [details]
sample app that outputs the Environment.TickCount every 3 seconds
were you able to follow the procedure to repeat this case?
I can CONFIRM this issue using the reproduction in https://bugzilla.xamarin.com/show_bug.cgi?id=58413#c3
08-21 17:42:59.340 I/TickCount(29899): Time:2070049083
08-21 17:43:02.375 I/TickCount(29899): Time:2070052117
08-21 17:43:05.415 I/TickCount(29899): Time:2070055157
...Changing time in Settings
08-21 21:43:01.046 I/TickCount(29899): Time:2084450789
08-21 21:43:04.078 I/TickCount(29899): Time:2084453820
08-21 21:43:07.120 I/TickCount(29899): Time:2084456862
Xamarin.Android SDK 188.8.131.52
Visual Studio 15.3
Hi Guys, any news on when this?
Hi, is there any update? It would be great to at least know when this is likely to be fixed as it is causing serious issues with our application
We have this issue reported as well:
We should look into taking the CoreCLR implementation which has support for monotonic time:
Candidate fix at https://github.com/mono/mono/pull/7520
What would be the estimated release date for this fix?
Would it be possible to get a hot fix release for this issue? We would love to validate this fix as soon as possible.
Fixed in master with https://github.com/mono/mono/commit/29c2ba9387fe094c672adedd27c56e46bfa3669c, in 5.12 with https://github.com/mono/mono/commit/cb89a1575c6ec93b6c70845bdc0f435b980231d5 and in 5.10 with https://github.com/mono/mono/commit/e3466bc3254ef548c04ba46b18842bafda380634
Small correction: The fix was reverted from 5.12 and 5.10 for now, because of some issues that are being resolved on master. They will be re-backported soon.