Because perfmgr is a vendor process, it cannot adjust system priority
directly.
Bug: 162791243
Test: build and using emul temp/running burn8 to verify it
Change-Id: I55e49cb7d0b2d4c0e42dff8398b5d42c6546cafa
(cherry picked from commit 1d87413881c5ef74c234d4a7cf4a8707ff0dccfe)
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
Return a positive integer for perf lock acquire and release so
that Goodix/FPC fingerprint sensor blobs will not complain.
Goodix:
E [goodixHAL][gf_hal_milan_f_series]: goodix_perf_lock_acquire: Failed to acquire perf lock, err: 0
E [goodixHAL][gf_hal_milan_f_series]: goodix_perf_lock_release: Perf lock release error 0
FPC:
E fpc_tac : fpc_perf_lock_acquire: Incorrect params, Failed to acquire perf lock, err
E fpc_tac : fpc_perf_lock_release: Perf lock release error 0
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
* proprietary perfd blobs can finally be nuked without breaking goodix
* we could even map the functions to use libperfmgr powerhints in the future
Signed-off-by: Lucchetto <lucchetto.tie@live.com>
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
565 I hwservicemanager: getTransport: Cannot find entry android.hardware.graphics.allocator@4.0::IAllocator/default in either framework or device manifest.
4126 W Gralloc4: allocator 3.x is not supported
565 I hwservicemanager: getTransport: Cannot find entry android.hardware.graphics.allocator@3.0::IAllocator/default in either framework or device manifest.
4126 W Gralloc3: allocator 3.x is not supported
4126 I Gralloc2: Adding additional valid usage bits: 0x0
Signed-off-by: pkm774 <mprabhat774@gmail.com>
This allows a device launched with Android O but now running
a 4.9-P+ kernel to declare itself as eBPF capable.
Fixes data usage on 4.9/4.14/4.19 kernels.
Change-Id: Ib44586f519ef0c5202ab841b8a1a8890e6ec74c7
init and friends are getting ratelimted on /dev/kmsg. Let's keep
the logs by setting printk.devkmsg=on.
Bug: 62952768
Test: Check for init logs in kernel during boot
Change-Id: I103e3cc1d73880af1d9a0cdc4dae05223eb4c427
Bug: 162791243
Bug: 72471476
Test: build and using emul temp/running burn8 to verify it
Change-Id: I5ca475be8b73b940e4858634595a7918ae92f6ef
(cherry picked from commit 35e110fe669a7d2996ce503d7e31204554f972e3)
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
- TDLS off-channel feature is needed only for certification.
- Disable the feature in production builds.
Test: Basic wifi sanity test.
Change-Id: I4bef76edb8663835953e45274805c5e15dfea808
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
* Breaking /product/overlay
* Also this makes many platform specific overlays with current system API on vendor partition which breaks newer android version compatibilities (broken stuffs in gsis)
Change-Id: I45eb18b0754726fb4f779521a0245dfcb1259b17
