Samsung Galaxy Centura
Time Keeping Issue
I recently purchased this cellphone (05/19/2014). I bought it from TracFone, and have had it for a couple of months. This is my first smartphone, and it has been a real learning curve. With everything that this phone is capable of, it is a real pleasure to use it. I was so impressed with this phone, I purchased another one for my wife. But (there is always a but...), it has one flaw that should never have made it to a production cellphone. The problem is its ability to keep accurate time.
At least once a day, both of these phones lose five hours. If it happens at local time 6:00 pm, the time on the cellphone will show 1:00 pm. This makes it impossible to use the clock to get the time, or create an accurate alarm. Imagine using one of these cellphones as an alarm clock. How many times can you be late for work?
As everyone does today, I made a search on the internet to see if anyone else has this problem. It turns out that the problem is fairly common! Not just with the cellphone that I have, but with many other Android based cellphones. Here is a link to a typical problem thread:
Time Keeps Changing Despite Settings
Here is another link to a discussion of the problem in a bug report:
Automatically set and track date/time via NTP
One thing that I quickly learned, is that I could power down the phone, and restart it. This forced the operating system to do a time lookup, and reset the internal clock. Reading the information on the internet, provided another way of doing a clock reset. This is by going into the cellphone settings, and turning off automatic clock update, and then turning it back on. At least, I do not have to power down the cellphone to reset the time.
Since I have more than 30 years experience in computer programming / system analysis, I decided to look into this further. My background includes many years using C, C++, and Java, including system level work as well as application development. So, I downloaded the Android Software Development Kit, and started learning the system. One thing I can say, is that my many years coding Java applications has helped in this endeavor! It also helps that I have spent many years working with Linux (including rolling my own).
So, here is a screen image of the timer App that I created to try to track down the cause of the problem:
This is the clock after the loss of five hours. It shows the failure state. As you can see, it displays the timezone ID, as well as the timezone name. Since I live in this timezone, this information is correct, and has not changed (according to the cellphone clock). So, the lost 5 hours does not appear to be a timezone issue.
The System Date displayed is the last time the cellphone was moved, or the orientation was changed. This timestamp is 5 hours behind local time since we are in the failure state. The SNTP Date is the last time the cellphone obtained a date from a SNTP time server. Finally, the timestamp displayed is based on the last SNTP lookup, but is the actual current local time. If you compare this timestamp with the clock timestamp in the upper right corner of the image, you will see the 5 hour difference.
Here is some more information that I obtained via the 'logcat' tool:
07-06 17:31:30.679 W/InputManagerService( 277): Focus gain on non-focused client
com.android.internal.view.IInputMethodClient$Stub$Proxy@4174b7c0 (uid=10062 pid=11219)
07-06 20:48:49.915 I/ActivityManager( 277): Start proc app.processName for
activity hostingNameStr: pid=11219 uid=10062 gids={3003, 1007}
07-06 20:48:50.125 D/MyClockApp.MyDigitalClock(11219): +MyDigitalClock(Content, AttributeSet)
07-06 20:48:50.125 D/MyClockApp.MyDigitalClock(11219): +initClock
07-06 20:48:50.145 D/MyClockApp.MyDigitalClock(11219): -initClock
07-06 20:48:50.145 D/MyClockApp.MyDigitalClock(11219): -MyDigitalClock(Content, AttributeSet)
07-06 20:48:50.145 D/MyClockApp(11219): +onStart
07-06 20:48:50.155 D/MyClockApp(11219): isAvailable: true
07-06 20:48:50.155 D/MyClockApp(11219): isConnected: true
07-06 20:48:50.155 D/MyClockApp(11219): isConnectedOrConnecting: true
07-06 20:48:50.155 D/MyClockApp(11219): isFailover: false
07-06 20:48:50.155 D/MyClockApp(11219): isRoaming: false
07-06 20:48:50.155 D/MyClockApp(11219): strExtra: null
07-06 20:48:50.155 D/MyClockApp(11219): strReason: null
07-06 20:48:50.155 D/MyClockApp(11219): iSubType: 0
07-06 20:48:50.155 D/MyClockApp(11219): strSubtypeName:
07-06 20:48:50.155 D/MyClockApp(11219): iType: 1
07-06 20:48:50.155 D/MyClockApp(11219): strType: WIFI
07-06 20:48:50.175 D/MyClockApp.SntpClient(11219): +requestTime
07-06 20:48:50.295 D/MyClockApp.SntpClient(11219): -requestTime
07-06 20:48:50.295 D/MyClockApp(11219): iCtr: 0
07-06 20:48:50.305 D/MyClockApp(11219): lNtpTime: 1404694131131
07-06 20:48:50.305 D/MyClockApp(11219): lElapsedRealtime: 34693300
07-06 20:48:50.315 D/MyClockApp(11219): lNtptimeReference: 34693294
07-06 20:48:50.315 D/MyClockApp(11219): lSNTPTime: 0
07-06 20:48:50.315 D/MyClockApp(11219): +Datetime
*(1) 07-06 20:48:50.315 D/MyClockApp(11219): Current time: Sun Jul 06 20:48:50 EDT 2014
07-06 20:48:50.335 D/MyClockApp(11219): -Datetime
07-06 20:48:50.335 D/MyClockApp(11219): +SNTPDatetime
07-06 20:48:50.335 D/MyClockApp(11219): lSNTPTime: 1404694131137
*(1) 07-06 20:48:50.335 D/MyClockApp(11219): SNTP Current time: Sun Jul 06 20:48:51 EDT 2014
07-06 20:48:50.335 D/MyClockApp(11219): -SNTPDatetime
07-06 20:48:50.345 D/MyClockApp(11219): strStorageLocation: /data/data/org.gophotog.myclockapp/files
07-06 20:48:50.345 D/MyClockApp(11219): -onStart
07-06 20:48:50.365 D/InputTransport(11219): Input channel constructed: ashmemFd=42, receivePipeFd=43, sendPipeFd=44
07-06 20:48:50.365 D/MyClockApp.MyDigitalClock(11219): +onAttachedToWindow
07-06 20:48:50.365 D/MyClockApp.MyDigitalClock(11219): -onAttachedToWindow
07-06 20:48:50.465 I/Adreno200-EGLSUB(11219): : Format RGBA_8888.
07-06 20:48:50.465 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x5092d000 size:7372800 offset:6758400 fd:49
07-06 20:48:50.725 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x5128e000 size:6758400 offset:6144000 fd:52
07-06 20:48:51.005 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x51a00000 size:1187840 offset:573440 fd:55
07-06 17:26:48.989 D/MyClockApp.MyDigitalClock(11219): +onDetachedFromWindow
07-06 17:26:48.989 D/MyClockApp.MyDigitalClock(11219): -onDetachedFromWindow
07-06 17:26:48.999 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x5092d000 size:7372800 offset:6758400
07-06 17:26:48.999 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x5128e000 size:6758400 offset:6144000
07-06 17:26:48.999 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x51a00000 size:1187840 offset:573440
07-06 17:26:49.049 D/InputTransport(11219): Input channel destroyed: ashmemFd=42, receivePipeFd=43, sendPipeFd=44
07-06 17:26:49.139 D/MyClockApp.MyDigitalClock(11219): +MyDigitalClock(Content, AttributeSet)
07-06 17:26:49.139 D/MyClockApp.MyDigitalClock(11219): +initClock
07-06 17:26:49.149 D/MyClockApp.MyDigitalClock(11219): -initClock
07-06 17:26:49.149 D/MyClockApp.MyDigitalClock(11219): -MyDigitalClock(Content, AttributeSet)
07-06 17:26:49.149 D/MyClockApp(11219): +onStart
07-06 17:26:49.169 D/MyClockApp(11219): isAvailable: true
07-06 17:26:49.169 D/MyClockApp(11219): isConnected: true
07-06 17:26:49.169 D/MyClockApp(11219): isConnectedOrConnecting: true
07-06 17:26:49.169 D/MyClockApp(11219): isFailover: false
07-06 17:26:49.169 D/MyClockApp(11219): isRoaming: false
07-06 17:26:49.169 D/MyClockApp(11219): strExtra: null
07-06 17:26:49.169 D/MyClockApp(11219): strReason: null
07-06 17:26:49.169 D/MyClockApp(11219): iSubType: 0
07-06 17:26:49.169 D/MyClockApp(11219): strSubtypeName:
07-06 17:26:49.169 D/MyClockApp(11219): iType: 1
07-06 17:26:49.169 D/MyClockApp(11219): strType: WIFI
07-06 17:26:49.319 D/MyClockApp.SntpClient(11219): +requestTime
07-06 17:26:49.469 D/MyClockApp.SntpClient(11219): -requestTime
07-06 17:26:49.469 D/MyClockApp(11219): iCtr: 0
07-06 17:26:49.469 D/MyClockApp(11219): lNtpTime: 1404700011582
07-06 17:26:49.469 D/MyClockApp(11219): lElapsedRealtime: 40573707
07-06 17:26:49.469 D/MyClockApp(11219): lNtptimeReference: 40573707
07-06 17:26:49.469 D/MyClockApp(11219): lSNTPTime: 1404694131137
07-06 17:26:49.469 D/MyClockApp(11219): +Datetime
*(2) 07-06 17:26:49.479 D/MyClockApp(11219): Current time: Sun Jul 06 17:26:49 EDT 2014
07-06 17:26:49.479 D/MyClockApp(11219): -Datetime
07-06 17:26:49.479 D/MyClockApp(11219): +SNTPDatetime
07-06 17:26:49.479 D/MyClockApp(11219): lSNTPTime: 1404700011582
*(2) 07-06 17:26:49.479 D/MyClockApp(11219): SNTP Current time: Sun Jul 06 22:26:51 EDT 2014
07-06 17:26:49.489 D/MyClockApp(11219): -SNTPDatetime
07-06 17:26:49.489 D/MyClockApp(11219): strStorageLocation: /data/data/org.gophotog.myclockapp/files
07-06 17:26:49.489 D/MyClockApp(11219): -onStart
07-06 17:26:49.509 D/InputTransport(11219): Input channel constructed: ashmemFd=44, receivePipeFd=47, sendPipeFd=48
07-06 17:26:49.519 D/MyClockApp.MyDigitalClock(11219): +onAttachedToWindow
07-06 17:26:49.519 D/MyClockApp.MyDigitalClock(11219): -onAttachedToWindow
07-06 17:26:49.559 I/Adreno200-EGLSUB(11219): : Format RGBA_8888.
07-06 17:26:49.569 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x5128e000 size:6758400 offset:6144000 fd:43
07-06 17:26:49.619 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x51b56000 size:7372800 offset:6758400 fd:51
07-06 17:26:49.779 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x50a33000 size:1806336 offset:1191936 fd:54
07-06 17:26:50.779 D/MyClockApp.MyDigitalClock(11219): +onDetachedFromWindow
07-06 17:26:50.779 D/MyClockApp.MyDigitalClock(11219): -onDetachedFromWindow
07-06 17:26:50.799 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x5128e000 size:6758400 offset:6144000
07-06 17:26:50.799 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x51b56000 size:7372800 offset:6758400
07-06 17:26:50.799 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x50a33000 size:1806336 offset:1191936
07-06 17:26:50.819 D/InputTransport(11219): Input channel destroyed: ashmemFd=44, receivePipeFd=47, sendPipeFd=48
07-06 17:26:50.899 D/MyClockApp.MyDigitalClock(11219): +MyDigitalClock(Content, AttributeSet)
07-06 17:26:50.899 D/MyClockApp.MyDigitalClock(11219): +initClock
07-06 17:26:50.909 D/MyClockApp.MyDigitalClock(11219): -initClock
07-06 17:26:50.909 D/MyClockApp.MyDigitalClock(11219): -MyDigitalClock(Content, AttributeSet)
07-06 18:04:02.539 D/InputTransport(11219): Input channel constructed: ashmemFd=44, receivePipeFd=47, sendPipeFd=48
07-06 18:04:02.549 D/MyClockApp.MyDigitalClock(11219): +onAttachedToWindow
07-06 18:04:02.549 D/MyClockApp.MyDigitalClock(11219): -onAttachedToWindow
07-06 18:04:02.579 I/Adreno200-EGLSUB(11219): : Format RGBA_8888.
07-06 18:04:02.579 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x51b56000 size:7311360 offset:6696960 fd:43
07-06 18:04:02.619 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x5127e000 size:1761280 offset:1146880 fd:51
07-06 18:04:02.779 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x5142c000 size:2375680 offset:1761280 fd:54
07-06 18:04:04.099 D/MyClockApp.MyDigitalClock(11219): +onDetachedFromWindow
07-06 18:04:04.099 D/MyClockApp.MyDigitalClock(11219): -onDetachedFromWindow
07-06 18:04:04.099 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x51b56000 size:7311360 offset:6696960
07-06 18:04:04.099 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x5127e000 size:1761280 offset:1146880
07-06 18:04:04.109 D/memalloc(11219): /dev/pmem: Unmapping buffer base:0x5142c000 size:2375680 offset:1761280
07-06 18:04:04.149 D/InputTransport(11219): Input channel destroyed: ashmemFd=44, receivePipeFd=47, sendPipeFd=48
07-06 18:04:04.269 D/MyClockApp.MyDigitalClock(11219): +MyDigitalClock(Content, AttributeSet)
07-06 18:04:04.279 D/MyClockApp.MyDigitalClock(11219): +initClock
07-06 18:04:04.289 D/MyClockApp.MyDigitalClock(11219): -initClock
07-06 18:04:04.289 D/MyClockApp.MyDigitalClock(11219): -MyDigitalClock(Content, AttributeSet)
07-06 18:04:04.289 D/MyClockApp(11219): +onStart
07-06 18:04:04.299 D/MyClockApp(11219): isAvailable: true
07-06 18:04:04.299 D/MyClockApp(11219): isConnected: true
07-06 18:04:04.299 D/MyClockApp(11219): isConnectedOrConnecting: true
07-06 18:04:04.299 D/MyClockApp(11219): isFailover: false
07-06 18:04:04.299 D/MyClockApp(11219): isRoaming: false
07-06 18:04:04.299 D/MyClockApp(11219): strExtra: null
07-06 18:04:04.299 D/MyClockApp(11219): strReason: null
07-06 18:04:04.299 D/MyClockApp(11219): iSubType: 0
07-06 18:04:04.299 D/MyClockApp(11219): strSubtypeName:
07-06 18:04:04.299 D/MyClockApp(11219): iType: 1
07-06 18:04:04.299 D/MyClockApp(11219): strType: WIFI
07-06 18:04:04.349 D/MyClockApp.SntpClient(11219): +requestTime
07-06 18:04:04.449 D/MyClockApp.SntpClient(11219): -requestTime
07-06 18:04:04.449 D/MyClockApp(11219): iCtr: 0
07-06 18:04:04.449 D/MyClockApp(11219): lNtpTime: 1404702246622
07-06 18:04:04.449 D/MyClockApp(11219): lElapsedRealtime: 42808687
07-06 18:04:04.449 D/MyClockApp(11219): lNtptimeReference: 42808686
07-06 18:04:04.449 D/MyClockApp(11219): lSNTPTime: 1404702244669
07-06 18:04:04.449 D/MyClockApp(11219): +Datetime
*(3) 07-06 18:04:04.449 D/MyClockApp(11219): Current time: Sun Jul 06 18:04:04 EDT 2014
07-06 18:04:04.459 D/MyClockApp(11219): -Datetime
07-06 18:04:04.459 D/MyClockApp(11219): +SNTPDatetime
07-06 18:04:04.459 D/MyClockApp(11219): lSNTPTime: 1404702246623
*(3) 07-06 18:04:04.469 D/MyClockApp(11219): SNTP Current time: Sun Jul 06 23:04:06 EDT 2014
07-06 18:04:04.469 D/MyClockApp(11219): -SNTPDatetime
07-06 18:04:04.469 D/MyClockApp(11219): strStorageLocation: /data/data/org.gophotog.myclockapp/files
07-06 18:04:04.469 D/MyClockApp(11219): -onStart
07-06 18:04:04.489 D/InputTransport(11219): Input channel constructed: ashmemFd=44, receivePipeFd=47, sendPipeFd=48
07-06 18:04:04.489 D/MyClockApp.MyDigitalClock(11219): +onAttachedToWindow
07-06 18:04:04.499 D/MyClockApp.MyDigitalClock(11219): -onAttachedToWindow
07-06 18:04:04.519 I/Adreno200-EGLSUB(11219): : Format RGBA_8888.
07-06 18:04:04.529 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x51b56000 size:7311360 offset:6696960 fd:43
07-06 18:04:04.549 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x50d41000 size:1187840 offset:573440 fd:51
07-06 18:04:04.799 D/memalloc(11219): /dev/pmem: Mapped buffer base:0x5127e000 size:1802240 offset:1187840 fd:54
In the log above, you can see that all timestamps agree for the first example: *(1). This shows 20:48:50 EDT for all timestamps.
When the failure occurs, you get what you see in the second example: *(2). The logcat timestamp shows 17:26:49, the cellphone current timestamp shows 17:26:49,
and the SNTP timestamp (which is the correct one) shows 22:26:51. So, internally, I have shown the problem.
Now, I understand that the lines in the logcat can be out of order, because of the way App logging is treated. But, I think by comparing all of the timestamps in the above log, you can see the failure. Here is an explanation of that:
Logcat has logs with timestamps out of sequence
If you want to see the entire logcat file, here it is:
Full Logcat file
I will try to update my findings over time. I have just scratched the surface. I have shown the symptom, but have not found the cause.
Tue Jul 8 14:13:33 EDT 2014
I decided to see what the logs would report when someone manually changed the time of the cellphone. I thought that it would give me an idea of what is being used when the failure state happens. Here is what I found:
07-08 11:42:00.430 I/ActivityManager( 276): Start proc app.processName for broadcast hostingNameStr: pid=7340 07-08 11:42:00.580 I/ActivityThread( 7340): Pub com.android.deskclock: com.android.deskclock.AlarmProvider 07-08 11:42:00.830 V/AlarmClock( 7340): AlarmInitReceiver finished 07-08 11:42:00.920 I/ActivityManager( 276): Start proc app.processName for broadcast hostingNameStr: pid=7370 07-08 11:42:01.000 D/ClockSync( 7370): Timer set, interval: 86400 07-08 11:42:01.000 D/ClockSync( 7370): Time changedThis type of information does not show up in the failed state logcat file. So, it is not happening via these processes.
I've found another reference as to who or what can change the cellphone's time. Here is a link:
How to set mobile system time and date in android
To make a long story short, you can only change the time by using a 'service' application. The only time you can access a service application, is if the operating system is running it, or you have 'rooted' your phone. So, there has to be an operating system application changing this time in error.
Tue Jul 10 16:09:12 EDT 2014
I modified my clock App to automatically output the logcat and the components of the bugreport. Now, I just need to wait until the failure state happens. I should be able to get all of the information available at the moment of failure.
Tue Jul 12 12:32:22 EDT 2014
I've been waiting two days for the cellphone to fail! It normally fails at least once per day. So, what has changed? My WiFi streaming music player died a couple of days ago. I had to remove it from the network. Could there be some sort of conflict or through-put issue? That was the only change, other than the hooks I put into the App to check for the failure state.
While I am waiting, I have been setting up a new Ubuntu desktop system and downloaded the Android OS software. I will compile it, and start looking at the source to determine who sets the system clock.
Tue Jul 14 18:48:22 EDT 2014
The cellphone finally failed! In looking for the log output, I have the following:
Full Logcat file
Partial Dumpstate file
If you look at the end of logcat file you will see the following:
07-14 18:47:38.390 V/StatusBar.BatteryController( 482): status5batteryHealth 2 07-14 18:47:38.390 D/StatusBar.BatteryController( 482): mOldstatus5status 5 07-14 13:48:16.810 D/MyClockApp.MyDigitalClock( 2907): +SNTPDatetime 07-14 13:48:16.810 D/MyClockApp.MyDigitalClock( 2907): lSNTPTime: 1405378097785 07-14 13:48:16.810 D/MyClockApp.MyDigitalClock( 2907): SNTP Current time: Mon Jul 14 18:48:17 EDT 2014 07-14 13:48:16.810 D/MyClockApp.MyDigitalClock( 2907): -SNTPDatetime *07-14 13:48:16.810 E/MyClockApp.MyDigitalClock( 2907): Failure lSNTPTime: 2014-07-14 18:48:17 07-14 13:48:16.810 D/MyClockApp.MyDigitalClock( 2907): +outputLog 07-14 13:48:16.860 D/MyClockApp.MyDigitalClock( 2907): strFileName: logcat_1405360096870.txt 07-14 13:48:16.860 D/MyClockApp.MyDigitalClock( 2907): getExternalCacheDir: /data/data/org.gophotog.myclockapp/files 07-14 13:48:16.860 D/MyClockApp.MyDigitalClock( 2907): outputFile: /data/data/org.gophotog.myclockapp/files/ logcat_1405360096870.txt 07-14 18:47:38.390 D/StatusBar.BatteryController( 482): now old status is 5
As you can see, the failure timestamp is 'Failure lSNTPTime: 2014-07-14 18:48:17' which is correct, but the logcat timestamp is '07-14 13:48:16.810'.
The last things completed before the failure (based on timestamp), are these:
07-14 18:47:55.640 W/SignalStrength( 275): getCdmaLevel=2 07-14 18:47:55.640 W/SignalStrength( 275): getEvdoLevel=0 07-14 18:47:55.640 W/SignalStrength( 275): getCdmaLevel=2 07-14 18:47:55.640 W/SignalStrength( 275): getLevel=2 07-14 18:47:55.650 W/SignalStrength( 482): getCdmaLevel=2 07-14 18:47:55.650 W/SignalStrength( 482): getEvdoLevel=0 07-14 18:47:55.650 W/SignalStrength( 482): getCdmaLevel=2 07-14 18:47:55.650 W/SignalStrength( 482): getLevel=2 07-14 18:47:55.670 E/WifiStateMachine( 275): set suspend optimizations failed! 07-14 18:47:56.130 E/WifiStateMachine( 275): set suspend optimizations failed! 07-14 18:48:05.700 D/Tethering( 275): interfaceLinkStateChanged wlan0, true 07-14 18:48:05.700 D/Tethering( 275): interfaceStatusChanged wlan0, true
So, what is Tethering? I have no idea! Something more to look into.
About the 'dumpstate' file. I'm not sure how much information is missing. Not very much I suspect. It does appear that the dumpstate process should have been in its own thread, because it blocked the output of 'dumpsys', which is normally part of a bugreport. I may change the App to put both into their own threads, and maybe I will get both of them.
Tue Jul 15 15:32:02 EDT 2014
I submitted a bug report to the Android Open Source Project:
Issue 73627: Clock regularly skews by 5 hours
Maybe they will be able to help track this problem down. At least, more technical types monitor the bug database, and may have some ideas.
Wed Jul 16 11:19:35 EDT 2014
I sent a link to this page, to Samsung. This is the reply that I got from them:
Dear Jonathan,
Thank you for contacting Samsung Telecommunications America.
After reviewing your e-mail, we understand that the clock on your device SCH-S738C keeps resetting itself.
We are sorry to inform you that, the support for Carrier related phone model (SCH-S738C) is not available with Samsung as the service and support for those models are provided by the Carrier.
The support for Carriers like Tracfone, StraightTalk and Net10 is provided by the concerned Carrier and Samsung support do not have the information to troubleshoot the issue.
We recommend you to contact the concerned Carrier support to get the exact information and troubleshooting to isolate the issue.
For your convenience, we will be providing their contact details for you. You can contact TracFone Voice support at 1-800-867-7183 or Click on the below mentioned web-link to reach them online. http://www.tracfone.com/contact.jsp.
We apologize for the inconvenience. We would have surely assisted you in all the possible ways in order to isolate the issue if we had any information about your device. Hope you understand our limitations.
Your satisfaction is of the utmost importance to us. Please feel free to get back to us, if you have any further queries. We will be glad to assist you.
You can also reach out to our chat support team by accessing the following link. Live Chat is available 24 hours a day 7 days a week. Have a wonderful day!
Link: http://www.samsung.com/us/support/contact
If you are looking for more details on the functionality of a product or would like to find answers to some of the questions, visit us at http://originus.samsung.com/us/smartphone-simulators-and-tutorials/# for an interactive review of some of our Samsung products.
Thank you for your continued interest in Samsung products.
Sincerely,
xxxxx,
Technical Support.
So, that looks like a dead end. I will try to contact TracFone, but I have not had a great experience with their technical support. Maybe it was just a bad day....
Thu Jul 17 10:34:09 EDT 2014
I heard from TracFone yesterday. Here is what they said:
Dear Jonathan,
Thank you for your interest in TracFone Wireless. We are responding to your recent inquiry.
Please be informed that the time of our TracFone handsets are system generated. Rest assured that we are doing our best to provide you the best service possible and we are continually working on improving and expanding our products and services.
If you have any further questions or concerns, please contact one of our customer care representatives at 1-800-867-7183. For your convenience, our representatives are available Monday-Sunday from 8:00 AM to 11:45 PM EST.
Thank you for being a TracFone Wireless customer. We appreciate your business.
Sincerely,
TracFone Wireless
Original Message Follows:
------------------------
This is the original message I sent you, why you did not get it I do not know. This information was provided on your contact page:
***********************************************************
The cell phone clock is not reliable. It losses 5 hours on a regular basis. This happens on my wife's Centura as well. Please see the following link that explains the issue: http://www.gophotog.org/android/
Can someone look into this? Is there a known solution? Please contact me via email, since I am hard of hearing.
Jon
***********************************************************
As it said in the above message, you should look at http://www.gophotog.org/android/ for a very detailed report of the issue.
I think the link I provide details the problem very well.
Thanks,
Jonathan Oman
On 7/16/2014 1:10 PM, TracFone Customer Service wrote:
> Dear Jonathan,
>
> Thank you for your interest in TracFone Wireless. We are responding to your recent inquiry.
>
> We have received an email from you. Unfortunately, your e-mail does not
> provide enough information for us to resolve your issue. Therefore,
> please reply to this e-mail with a more descriptive inquiry. We will be
> more than glad to help you getting your concern(s) solved as soon as
> possible.
>
> If you have any further questions or concerns, please contact one of our
> customer care representatives at 1-800-867-7183. For your convenience,
> our representatives are available Monday-Sunday from 8:00 AM to 11:45 PM
> EST.
>
> Thank you for being a TracFone Wireless customer. We appreciate your
> business.
>
> Sincerely,
>
> TracFone Wireless
I'm sure that the TracFone technical people are diligently working on this issue. We should see an update to our phone's software in the next few weeks!
Thu Aug 28 14:34:41 EDT 2014
I have not had time to work on this lately. But, I noticed that the cellphone would actually correct its time after a failure. This could be many hours after the cellphone time lost the five hours. When I noticed that this was happening, I changed my Apps code to dump the state of the cellphone when the correction happened.
Here is the complete logcat and dumpstate files after the correction:
Full Logcat file
Full Dumpstate file