Network time detection

Android devices automatically attempt to obtain the correct Unix epoch time from a network source. Android uses the SNTP protocol, which uses the UDP protocol, to obtain time information.

The components described on this page are part of the automatic time detection system referred to as the network time origin. A time signal from a network time server can be used to set the Android device's system clock when automatic time detection is supported on the device and the time_detector service is configured to use it.

By default, Android uses the network time origin as the primary automatic time detection origin.

Network time detection system

The network_time_update_service service that runs in the Android system server implements the network time detection system. The service periodically uses SNTP to obtain a time signal from a server. The service also monitors network connectivity and triggers a time refresh when no recent time signal is available after extended periods of poor connectivity.

The network_time_update_service service attempts to obtain a time signal after boot and when network connectivity is first established. The service then tries to keep the latest signal it holds fresh. It balances the needs of individual Android devices with the substantial load that could be generated by many Android devices worldwide refreshing their time.

Using internal APIs, network_time_update_service submits network time suggestions to the time_detector service. Other Android platform components then use these network time suggestions.

After receiving suggestions from the network time origin, the time_detector service determines whether to update the system clock according to the configured prioritization rules.

To configure the automatic time detection system to use the network origin suggestions to set the system clock automatically, use the core/res/res/values/config.xml system server configuration file. Ensure the value network is contained in config_autoTimeSourcesPriority in the desired position. For details, see Time Source Priority.

Device configuration

This section describes how device manufacturers can configure the network time detection system.

The base AOSP configuration is at frameworks/base/core/res/res/values/config.xml:

Configuration key AOSP value Description
config_ntpRetry 3 After failing to refresh, this is the number of times the system tries network time polling with a shorter NTP polling interval (config_ntpPollingIntervalShorter), before backing off and using the normal polling interval (config_ntpPollingInterval). A value less than 0 means the system retries polling at the shorter NTP polling interval until it's able to successfully refresh.
config_ntpPollingInterval 64800000 (18 hours) The normal network time polling interval in milliseconds.
config_ntpPollingIntervalShorter 60000 (1 minute) The retry network time polling interval in milliseconds. Used when a time refresh fails.
config_ntpServers A single entry: ntp:// NTP servers to use to obtain an accurate time. Items must be in the form: ntp://<host>[:port].
This isn't a registered IANA URI scheme.
config_ntpTimeout 5000 Time to wait for an NTP server response in milliseconds before timeout.


By default, AOSP uses time servers at, which is an alias for Google Public NTP. This service has no SLA. For details, see the Google Public NTP FAQ.

Multiple server support

For Android 14 and higher, the framework supports multiple NTP servers. This supports situations where devices are distributed globally with a single configuration, but where access to servers such as is restricted in certain places.

The algorithm tries each server specified in the config_ntpServers configuration key. When it finds one that responds, the system continues using that server until it fails to refresh or the device reboots.


Android's default network time sync uses SNTP with a single time query approximately once a day to try to ensure it always has a recent time signal.

Network latency effects are the biggest contributor to time inaccuracy with Android's SNTP implementation. SNTP assumes symmetric network delays, that is, the network latency for the request is the same as the network latency for the response, and the correct time lies exactly in the middle of that network round trip. Often, network round trip time is in the order of a few hundred milliseconds and on a wired network the latency is close to symmetric, leading to levels of inaccuracy that are near imperceptible to users. However, with mobile or radio telephony there are several stages where relatively long, asymmetric delays can be inserted into a network transaction leading to greater inaccuracy.

With the AOSP default setting for config_ntpTimeout set to 5000 milliseconds, and if all network latency is solely concentrated on the inbound or outbound leg, the maximum theoretical error is approximately 2.5 seconds.

Overall system clock accuracy is also affected by the Android device's ability to track elapsed time accurately after a time signal is obtained. This is a concern with all timekeeping on Android, not just network time detection, and is why the time_detector service disregards old time suggestions. The network_time_update_service service refreshes regularly using the config_ntpPollingInterval interval to keep the time_detector service supplied with fresh time suggestions and to ensure that the time_detector service doesn't fall back to lower-priority and often lower-accuracy or occasionally incorrect time origins such as telephony.

When automatic time detection is used, device system clock accuracy can be affected by other configurations of the time_detector service, such as the constants and flags that affect how different a time suggestion has to be from the current system clock time before the clock is adjusted (

Device manufacturers can modify accuracy using the preceding configuration options and constants. But it's important to be aware of the limitations of the platform's SNTP implementation, and the potential impact on power consumption from more frequent network operations, impact to apps running on the device from more frequent but smaller clock adjustments, and the effect on server load.

Other uses of network time

If automatic time detection using the network origin isn't configured or if the user has disabled automatic time detection, the time obtained by the network_time_update_service service is still used by the following components:

Debugging and testing

The following section describes shell commands for debugging and testing the network time detection feature.

Interact with the network_time_update_service service

To dump the current state of network_time_update_service, use:

adb shell cmd network_time_update_service dump

To see a set of command line options that can assist with testing, use:

adb shell cmd network_time_update_service help