* The anti-falsing implementation from HumanInteractionClassifier
regularly prevents easy swipe to unlock or to pattern / pin
on the keyguard lockscreen, requiring multiple attempts
until accepted due to a hardcoded evaluation (5.0f)
while normal usage shows better results without it
* Another solved situation is remote device access like
Vysor or TeamViewer were the device is almost impossible
to swipe properly from a computer client
Change-Id: I0c2590f56e2cf6d6cd4ff3af2341a985670168e3
Signed-off-by: Adrian DC <radian.dc@gmail.com>
Signed-off-by: RenanQueiroz <queirozrrq@gmail.com>
Pin critical system apps that always need to be responsive, no
mattter what:
- SystemUI for expanding the notification shade/navigation bar
- SF: Doesn't need introduction, but still gets zram'ed in certain
cases:
Total memory impact: About 5-6 MB (since regularly not all code is
loaded)
Test: Flash device with CL and make sure actions like expanding
notification shade isn't as janky under memory pressure anymore
Bug: 111132016
[aviraxp]: Original code pins the pre-odexed file of SytemUI, but we
do not dexpreopt priv-apps. So pin the SystemUI apk as well
just as what it is for camera pinning.
Change-Id: I3bc93204147502bec2e983f7ee37555294db308c
* This fixes the following error on camera-in-mediaserver devices:
E CameraService_proxy: Calling UID: 1013 doesn't match expected camera service UID!
Change-Id: I185e34e8983b286436bfc0fe36cfdf260ef78170
The files in arm/arm64 are symlinks and pinning symlinks is not
supported. Pin the target vdex file intead.
Bug: 73990433
Test: manual
Change-Id: I313e1f53487c0a21b615f65dc64c21a1ecb4b7d5
.vdex files have been added to allow pre-verified dex. The pinner
service needs to take this in account when pinning. Add pinning of
appropriate system .vdex files on 8996 targets.
Bug 33168521
Test: Tested manually by confirming pinning is successful
Change-Id: Ice2c3f0ec0b314963fb136793d9fa36ecba58490
* Pin key files into memory to prevent having to fetch from flash
after boot. Improves system performance by preventing page cache
thrash. Retrieves files from a device-specific overlay to allow
specialization.
Change-Id: I53f8227c66c44d3955422b41d623e450ec2be421
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
* These should be set appropriately by carrier, and should already be
at the correct values by default in packages/apps/CarrierConfig
Change-Id: I433b110570c2b79b15076dadf58777e0289e347a
* 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
