* Logs spam with error '-13' which basically translates to access denied/invalid permission.
* Fix this by giving system read and write access.
Before in log:
Diag_Lib: Diag_LSM_Init: Failed to open handle to diag driver, error = 13
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
* uprev fcm to level 4
* move fod and touch hal to vintf_fragments
* remove manifest entries of unused HALs
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
Use dex2oat64, and drop deprecated flags
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Change-Id: I42a7d87ab7f0af20b9c3f5bacba37ab0b0b529f1
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
What happens is that HBM is being turned off in lower level and the node is not being updated.
Writing 0 to node when the screen turns off to go around that.
Service only runs when HBM is turned on.
it stops itself when the screen turns off / HBM is turned off
Also remove some useless code all around and slightly improve...
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
Have the preference change listeners inside DeviceSettings -
This allows us to always correctly display forced 90Hz peak rate state.
What happened before is that you could enable and disable auto refresh rate
and forced peak would retain its state, even though practically it's disabled now.
Also correctly check if forced peak refresh rate is currently enabled -
We need to check both min & max refresh rate settings values
Both logic errors together caused a state that forced peak refresh rate always shows enabled,
even if you fully reopen the app, but truly is disabled and needs re-setting to actually work!
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
@idoybh edits:
* Adapted to camera_helper
* Use current intent reciever to check for screen on / off
* Simplified some code
Co-authored-by: idoybh <idoybh2@gmail.com>
Prebuilt apps like Gmail/Google App, will be updated by google play, and there is no need spend time and space optimising what is going to be replaced.
Switch to Google's recommendation of using verify for an OTA package.
Applications still stay on speed.
Instead, replace the install profile with speed-profile making apps perform better.
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
When I went through https://source.android.com/devices/tech/dalvik/configure my previous configs felt wrong, this one should be perfect (I hope).
Even though there is a slight trade-off for boot time by using the speed profile, we do make up for it by using 8 threads.
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER attempts to compile all prebuilts fully optimised to speed level, thus the phone doesnt need to deal with it.
I also do know that this might be a trade-off on size, but I do see the first boot time is more worthy to trade-off.
The speed level mentioned here runs dex verification and compiles all AOT methods.
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
In Android R, the SurfaceFlinger calculate phase offsets
based on duration. Adopt the new way of specifying
phase offsets to SurfaceFlinger.
Bug: 143933518
Bug: 142222407
Test: scrolling, app launching/closing, playing video
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
Enable backpressure for client composition to avoid jank due to
HWC queue stuffing.
Bug: 151113311
Test: 1. Swipe up/down Notification shade.
2. Measure the "FrameMissed" count from systrace result
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
This addresses an underlying problem since /dev/hw_random is used. The
issue is that EntropyMixer, which runs in system_server, needs to read
from /dev/hw_random, but thanks to our qualcomm ueventd, EntropyMixer
can never accress this node, resulting in warnings like this:
W EntropyMixer: Failed to add HW RNG output to entropy pool
W EntropyMixer: java.io.FileNotFoundException: /dev/hw_random (Permission denied)
AOSP ueventd handles this well, so just remove this line to get things
back to stage. This issue was never exposed because Google derps the
logging here, which is already fixed on Pie.
c78a463e87
Change-Id: I42c9aaa8f57306536e51c0a17febad57a5a77581
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
* Used multiple threads and speed profile to hasten the first boot
Signed-off-by: baalajimaestro <me@baalajimaestro.me>
Change-Id: I2cce5ddf7d50308511e81436fcac613b2c6537bf
This change yields considerable SQLite performance gains. It should be generally safe as this device has irremovable battery.
Some OEMs have been doing this for years.
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
There is no evidence that Qualcomm devices running a rather recent IMS
stack need to include AOSP RCS packages. RCS already worked before this
change and continues to do so, but the main goal was to get rid of some
of the RCS related log spam, which was accomplished here.
Change-Id: I219546e29d288373877e9bcd194a60ef5e09f224
Signed-off-by: Omkar Chandorkar <gotenksIN@aosip.dev>
LuK1337
Omkar Chandorkar
Vishal Cj
baalajimaestro
Adam Shih
Kuba Wojciechowski
Ido Ben-Hur
ZONGQUAN-HU
rituj
Nauval Rizky
Omkar Chandorkar
John Galt
tangrobin
Wang Han
Jesse Chan
Bruno Martins