Testing response times to time.android.com from around the globe reveals
in ms:-
Europe <30
Middle East <68
North America <150
Johannesburg 183
Buenos Aires 220
Tokyo 226
Sydney 276
Hong Kong 285
Brisbane 295
Mumbai 349
Beijing 4691
Shanghai 4906
Russia n/a
Whilst time.android.com is NOT used for GPS NTP, North American time servers
are, by specifying north-america.pool.ntp.org as default in the framework,
to align with pixel devices. I am assuming similar response times to these
servers from around the world.
Great for North America and it appears Europe but it does not address the
global issue. Also, the pool.ntp.org project forbids both hardware and
software vendors from using these default zone names.
http://www.pool.ntp.org/en/vendors.html
It makes sense, therefore, to leverage the ntp.org's existing 'android' vendor
name to make the default ntp server for GPS purposes:
1.android.pool.ntp.org this will return a random but accurate NTP server in
close geopraphic proximity to the device.
Testing on my own build in the UK seems to improve hot and cold TTFF
considerably.
Change-Id: I144af45757efa35b32daf034eece6e046d2bde79
* XTRA_SERVERs are important, right? Like to get the almanac data
necessary for aGPS. Without the XTRA download, the chip needs to
collect sufficient navigation messages from the birds to compute
where they are in order to make sense of the ranging signals.
* Well, it seems that O doesn't like reading these entries from the
gps.conf file.
When in gps.conf:
GpsXtraDownloader: No XTRA servers were specified in the GPS configuration
When in overlay:
<that noise doesn't exist>
* This seems to, finally, return GPS fix performance to what we had
in N.
Change-Id: I70679835ec5dea053c5aa3750acee628906d6390
