Android 时间同步机制及常见问题分析

近期Android设备多次遇到时间不准的问题，借此机会分析Android 时间同步更新机制。

此篇文章将分析Android 时间同步更新机制的构成及常见导致时间不准的情况。

一.Android 时间同步更新机制的构成:

1.由android启动流程可知，系统服务由SystemServer启动，在SystemServer查找到时间更新服务。

SystemServer->startOtherServices->networkTimeUpdaterF.systemRunning();

 2.NetworkTimeUpdateService启动后首先发出EVENT_POLL_NETWORK_TIME调用onPollNetworkTime()尝试更新时间，

看样子onPollNetworkTime（）似乎是时间更新的核心，看看它干了什么。

①处首先检查是否开启了时间同步更新，也就是设置里时间自动选项，开启了才会更新时间。

②处对距离上次时间更新的时间间隔有要求，mPollingIntervalMs从配置文件获取到时间间隔24h,也就是距离上次更新不到24h不会再次更新时间

此处mNitzTimeSetTime !=NOT_SET有什么作用，后面再表，先往下看。

③处，满足更新条件后mTime.forceRefresh()更新时间，往下看forceRefresh()

看样子是调用client.requestTime(mServer, (int)mTimeout)访问地址为mServer的服务器发出sntp请求，sntp通过什么方式请求呢？继续往下看：

到

到这里我们可以知道sntp实质是向host name 为mServer的主机发出UDP来更新时间，更新到的时间赋值给了mNtpTime，在onPollNetworkTime（）通过④处SystemClock.setCurrentTimeMillis(ntp)设置系统时间，到这里时间更新完成。

就这么结束了吗？当然不是！如果时间同步失败，有重试机制吗？同步更新成功，下次什么时候更新？

第⑤处回答了我们，有重试机制，最大重试次数mTryAgainTimesMax=3，间隔时间mPollingIntervalShorterMs为1分钟；同步成功的话，间隔mPollingIntervalMs再次检查更新，也就是24h（当然了，如果重试3次仍然失败也会24h后尝试更新）.

如果设备网络不通，最大重试次数mTryAgainTimesMax用完，就得24h后再更新？？？

当时不是，android替你想好了，回顾下systemRunning():

systemRunning（）注册了网络状态监听，网络变化时发出EVENT_NETWORK_CHANGED->onPollNetworkTime（）尝试更新时间.

到这里，我们已经知道Android 可以通过sntp从网络更新时间。Android时间更新似乎也就仅此而已。

等等，在②处有个疑问还没解开，mNitzTimeSetTime !=NOT_SET有什么用处？

回头看：

mNitzTimeSetTime 初始值为NOT_SET，我们自然可以通过sntp从网络更新时间，那么为什么要设置这个条件？

除非还有另一种时间更新机制，如果这种机制同步了时间，自然不必再通过sntp同步时间！

那就看看mNitzTimeSetTime 在哪里被赋值为！=NOT_SET

是谁发出了这个ACTION_NETWORK_SET_TIME广播告诉NetworkTimeUpdateService不必多此一举通过sntp更新时间？再看：

原来是GsmServiceStateTracker接收到EVENT_NITZ_TIME->setTimeFromNITZString()->setAndBroadcastNetworkSetTime()设置了时间并发出广播告知NetworkTimeUpdateService不必多次一举，弟弟已替你更新了时间，哥哥就不必徒劳了！

一探究竟，GsmServiceStateTracke实质只是个Handler，传递信息罢了，谁发送的消息呢？顺着EVENT_NITZ_TIME这一线索继续看。

找到CommandsInterface实现类BaseCommands

GsmServiceStateTracke把自身以及EVENT_NITZ_TIME这一Message设置进了BaseCommands包装成了Registrant对象mNITZTimeRegistrant，

那么好办了，找到mNITZTimeRegistrant哪里被调用就知道谁发出的消息。

原来是RIL processUnsolicited()接收到RIL_UNSOL_NITZ_TIME_RECEIVED事件发出，继续往下看：

现在很清晰了，RIL里启动了线程RILReceiver,RILReceiver通过socket 与rild通信，读出了时间值->processResponse()向上分发，这种时间同步机制称为NITZ（通过基站同步时间）。

RILD何物？

RILD:Radio Interface Layer  Deamon,承接Android 上层 （RILJ）与 Modem的通信。草图如下：

至此，知道了Android时间同步更新机制有SNTP和NITZ两种方式。

二.常见导致时间不准的情况及解决途径：

常遇到的问题是NITZ时间不准，导致系统时间不准。

从Android时间同步机制分析知道，如果NITZ同步了时间，SNTP在24h内不会被触发。如果NITZ同步了错误的时间，短期内设备仍旧是错误的时间直到SNTP被触发。怎么确认呢？

分析GsmServiceStateTracker setTimeFromNITZString()可知，更新NITZ时间后，会通过SystemProperties.set("gsm.nitz.time", String.valueOf(c.getTimeInMillis()))写入临时变量并输出日志"setAndBroadcastNetworkSetTime: time"，与设备开机时的时间比较便知NITZ时间是否有误。

解决：NITZ时间不准，通常是由基站导致，可以通过如下任意一种方式解决：

1.通过配置关闭NITZ机制只保留SNTP解决：

分析GsmServiceStateTracker setTimeFromNITZString()可知设置gsm.ignore-nitz为true,就不会设置NITZ时间为系统时间，这样就从SNTP同步时间。

这么做需要个前提，就是系统开放了管理员权限，这样才可以把gsm.ignore-nitz=true配置固化（build.prop）。

2.写个系统应用：

关闭自动同步时间开关，这样就关闭了系统时间同步机制，同时借鉴SNTP机制，写一套sntp，在应用上更新时间。