on Android 16, this causes logspam of "W libc : Unable to set property "ctl.interface_start" to "aidl/stats": PROP_ERROR_HANDLE_CONTROL_MESSAGE (0x20)"
did google fix the battery drain?
Signed-off-by: thepriyanshujangid <priyanshujangid@yahoo.com>
These are critical for display performance and should not be balanced
in order to improve latency and responsiveness.
And also affine them.
Change-Id: If49ecb8757d133a7fad0d7946837b35403e57c2a
This service hogs a considerable amount of CPU all the time as its
busy calculating compensation for our under-display light sensor
(and also spamming logcat, which we can take care of later).
PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ ARGS
1969 system 20 0 12G 9.2M 9.0M S 4.6 0.1 1:13.15
vendor.xiaomi.sensor.citsensorservice@2.0-service
Move it to background CPU set like the sensors multihal to lower
power consumption from big cores.
Change-Id: I8c7b2835b2b53654642ac20fd97df3b8a5ad96eb
needed for using EdgeTpu.
Due to this code goes to AOSP, please see CL details and test result in
b/289097511#comment24.
Bug: 289097511
Change-Id: Ie0969309346cd85b4bb8ac71860a529710c73345
While implementing the capo nanoapp for audio configuration, we met
some chre socket connected error due to the access group denied.
Add context_hub group for audio hal to connect chre socket.
go/capo-algo
Bug: 141128522
Bug: 149069556
Test: FULL build with audio hal part and local prebuilts nanoapp.
Test: Audio HAL communicates normally with CHRE socket.
Change-Id: Iea84411682f4c3e08f8b37a5b21818b0e9b04983
Looks like apps like Network Signal Guru connects to the diag-router
through an emulated(?) USB device.
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
Audio HAL initialization relies on rpc daemon to load
dynamic libs, if daemon is not ready when HAL tries
to load libs, HAL has to wait until that finished.
Start this daemon early can smooth boot up of audio HAL
process, as this can save time for dynamic libs loading.
Change-Id: Id05ffc46fab812a718b6cb601e0610974b123679
Signed-off-by: JaswalAshish <ashish@m.ms.evolution-x.org>
Since Ext4 doesn't implement "-o sync", it commits metadata at every 5 secs.
This may cause /metadata corruption.
Bug: 162883014
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Signed-off-by: Randall Huang <huangrandall@google.com>
Signed-off-by: Vaisakh Murali <mvaisakh@statixos.com>
Signed-off-by: ralph950412 <ralph950412@gmail.com>
Change-Id: Icd38754bad1b1529d01165ea8c703c214d20bb4b
* Greatly affects the performance/latency of the display
considering you have foreground set to 0-6 cores on <SM7350
whilst being power efficient.
* This shows an improvement on HWUI graph and even jankbench.
This service hogs a considerable amount of CPU all the time as its
busy calculating compensation for our under-display light sensor
(and also spamming logcat, which we can take care of later).
PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ ARGS
1969 system 20 0 12G 9.2M 9.0M S 4.6 0.1 1:13.15 vendor.xiaomi.sensor.citsensorservice@1.1-service
Move it to background CPU set like the sensors multihal to lower
power consumption from big cores.
With SurfaceFlinger and HWC on the foreground cpuset,
important rendering tasks are moved off of the background
cpusets, so let's reserve one little core for foreground
and top-app.
Change-Id: I4f0982f3ff4dce756095667df0d08f18817b896a
The restricted cpuset is for system tasks that are
throttled because the screen is off. Google only
runs these tasks on the little cluster
to save power and we will follow suit.
The Cortex-X1 core is quite power hungary. Let's only use it for
top-app tasks. Avoid migrating foreground tasks to X1 to reduce
unnecessary bumps of X1's frequency and save some battery.
The health AIDL HAL service provides functionalities of charger,
therefore system charger at /system/bin/charger is deprecated.
On top of that, QTI health AIDL HAL service enables suspend by
default, the equivalent of setting ro.charger.enable_suspend
for legacy charger.
Change-Id: I59c23e7974cea1174b0161f31a535fa3afa1e5c9
[Tashar02]:
- In sm8350 family, redwood is an exception where the Indian variant
does not contain NFC; only the China and Global variant do.
- This patch is imported from [1] and adapted to sm8350-common accordingly
based on patchset [2].
[1] https://github.com/cupid-development/android_device_xiaomi_sm8450-common
[2] sm8450-common: Allow choosing NFC supported SKUs
sm8450-common: Build nxp nfc service from source
sm8450-common: Remove more nfc related features for non nfc skus
sm8450-common: Don't override nfc services for no nfc skus
sm8450-common: Drop nfc services from manifest since they have fragments
Change-Id: Ia14a6c93e6320c8dfa1df2957e19b51a267c2234
Co-authored-by: Arian <arian.kulmer@web.de>
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Signed-off-by: thepriyanshujangid <priyanshujangid@yahoo.com>
