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
Some location libraries are spamming logcat with function traces.
Decrease the priority of these logs to prevent them from flooding
logcat.
Change-Id: I7b105684c8c9ba0ce67e5302bb7a003f1af7c90d
libloc_pla is playing tricks with -Wl,--export-dynamic to use symbols
from libandroid_runtime without depending on it. libandroid_runtime's
headers are moving to where they are only exported to modules that
depend on it, so add a dependency and remove -Wl,--export-dynamic
Bug: 33630870
Test: builds
Change-Id: I9b0567a48ded63031085b6ba93fb3b36404279e1
(cherry picked from commit ada652709d5a1b9faedecc02739d2ed610e18f86)
