Bug 58413 - Environment.Tickcount is changed when the date is changed in android
Summary: Environment.Tickcount is changed when the date is changed in android
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 5.1
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2017-07-26 14:57 UTC by Rowan
Modified: 2018-05-02 22:12 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

sample app that outputs the Environment.TickCount every 3 seconds (43.14 KB, application/x-zip-compressed)
2017-07-26 15:58 UTC, Rowan

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Rowan 2017-07-26 14:57:17 UTC
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
Comment 1 Jon Douglas [MSFT] 2017-07-26 15:25:30 UTC
Hi Rowan,

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!
Comment 2 Rowan 2017-07-26 15:57:13 UTC
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()
            while (true)
                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.
Comment 3 Rowan 2017-07-26 15:58:11 UTC
Created attachment 23822 [details]
sample app that outputs the Environment.TickCount every 3 seconds
Comment 4 Rowan 2017-08-01 22:31:02 UTC
were you able to follow the procedure to repeat this case?
Comment 5 Jon Douglas [MSFT] 2017-08-21 21:56:30 UTC
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

Version Information:

Xamarin.Android SDK
Visual Studio 15.3
Comment 6 Rowan 2017-09-09 12:29:33 UTC
Hi Guys, any news on when this?
Comment 7 Rowan 2017-10-23 15:55:01 UTC
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
Comment 8 Miguel de Icaza [MSFT] 2018-03-08 20:47:22 UTC
We have this issue reported as well:


We should look into taking the CoreCLR implementation which has support for monotonic time:

Comment 9 Alexis Christoforides 2018-03-09 04:15:14 UTC
Candidate fix at https://github.com/mono/mono/pull/7520
Comment 10 Rowan 2018-03-10 16:35:18 UTC
Great news! 

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.
Comment 12 Alexis Christoforides 2018-03-20 15:42:09 UTC
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.
Comment 13 Rowan 2018-04-20 16:54:14 UTC
Is there any news about this? Is there some indication When this will be included in a release? We would like to test this ASAP.
Comment 14 Jonathan Pryor 2018-04-23 19:55:09 UTC
@Rowan: At this point in time this fix will NOT appear in Visual Studio 15.7/Xamarin.Android 8.3, at least not in the initial stable release. As @Alexis mentioned, the fix in mono/2017-12 -- which Xamarin.Android 8.3 uses -- has been reverted, so *at present* we will need to wait for Xamarin.Android 8.4 for the fix.

(It is instead possible that it will be fixed in mono/2017-12 and provided in a future update to 15.7.x, but I do not know if that will actually happen.)
Comment 15 Jonathan Pryor 2018-05-02 21:25:24 UTC
@Rowan: As it turns out, I'm wrong. The fix is now in mono/2017-12, and should be part of Visual Studio 2017 15.7 Preview 5 or 6 (I forget which):

Comment 16 Rowan 2018-05-02 22:12:05 UTC
wow thats great news! thanks!