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
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 5.1
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2017-07-26 14:57 UTC by Rowan
Modified: 2017-10-23 15:55 UTC (History)
3 users (show)

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


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

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)
            {
                Thread.Sleep(3000);
                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 4.6.0.295
Xamarin.Android SDK 7.4.0.19
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

Note You need to log in before you can comment on or make changes to this bug.