* Oddly, disabling MAC randomization fully breaks AP, which really
just points to a platform problem. But it seems that our device
can actually handle the "randomization", which doesn't actually
randomize anything (for us). ¯\_(ツ)_/¯
This reverts commit 1e39b786ec.
Change-Id: I8bbcdb968a08f0c700cf436cfdde453b51f96170
Config overlay values moved from frameworks_base core to
frameworks_base packages/Tethering
https://github.com/LineageOS/android_frameworks_base/blob/lineage-18.0/packages/Tethering/res/values/config.xml
[haggertk: As part of this move, I'm consolidating these from
{h,k}lte-common to msm8974-common. These held common values between
the two device families.]
Original-Change-Id: Ia5a8056d6334cd78e79853c0ada4e8873a9669e0
Change-Id: I54e93e80595c243719894aa1b9ff0c5abf85d843
[haggertk: As part of this move, I'm consolidating common values from
{h,k}lte-common to msm8974-common.]
Original-Change-Id: I747d0242422b753f4e3007ce6c4bf7f124c52c5e
Change-Id: I516b5a3b34747bd7a9efb93eacb8b597da513d54
* Even though the stock gps_debug.conf says that you put
customization in fw/b overlays, Q doesn't look to those anymore.
* With XTRA_SERVERs in those overlays you get:
GpsPsdsDownloader: No PSDS servers were specified in the GPS configuration
This reverts commit 399e9af90a.
Change-Id: Id392cf4a9b91a63a4400e546bc9ba4c32b656ef4
SUPL_ES=1 ensures the GnssLocationProvider and related framework code
accepts incoming SMS SUPL_INIT messages with ES-bit=1
(which allow redirection of the ESLP
end-point e.g. to the current local emergency services provider when
you are travelling) only during an emergency call
Bug: 115331218
Bug: 112159033
Test: Build pass
Change-Id: I5075f7887a184ce18bb1815b35a2ce7acd8bca10
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
* Remove duplicate keylayouts
* Move media_codecs to platform tree
* Unconditionally build consumerir
* Move postrecoveryboot to qcom-common
* Move common msm8974 HAL/packages to platform tree
* Move wifi config to device trees
* Use nested cm.dependencies
* Generate firmware symlinks at compile time
* Move egl.cfg to msm8974-common
* Move QCOM_BSP to platform repos
* Move telephony permissions to device
* Move reboot to download option to qcom-common
* Move common overlay options to qcom-common
Change-Id: I493dcf24269e852e7819c045dc3afc5c47da176a
