* trace:
E AndroidRuntime: java.lang.IllegalStateException
E AndroidRuntime: at android.media.MediaPlayer._stop(Native Method)
E AndroidRuntime: at android.media.MediaPlayer.stop(MediaPlayer.java:1397)
* also do small refactoring while at it
Former-commit-id: 98f1335384a6b534becf87ad54333f737de9e15e
Signed-off-by: Joey Huab <joey@evolution-x.org>
In Android 14, prioritization of partitions is emphasized, diverging
from previous versions where priorities were respected universally.
Overlay precedence now plays a critical role, with the following
partition order dictating overlay precedence:
- system
- vendor
- odm
- oem
- product
- system_ext
When multiple overlays contend for the same resources, the order of
overlays becomes crucial. An overlay takes precedence over others if it
has configurations following its own. This prioritization, while
impactful for GSI compatibility, is essential for maintaining order and
functionality.
* (pix106) Only WifiOverlay packages did not have vendor explicitely defined
Change-Id: I8b7568dcc418dbbd1ccb39e2d0dc66504f19fcdd
This is enabled by default on U, and it causes apps like
Chrome and YouTube to render the frame rate at 30FPS when
playing some videos.
Change-Id: I649bf03d550c2b9726c7957d15ed09e455d874ec
Signed-off-by: clarencelol <clarencekuiek@proton.me>
Signed-off-by: pix106 <sbordenave@gmail.com>
The first default zram write back time is 3 hours which
is for go device to quickly save more ram. For Pixel
devices, we have more working set and could bring launch
time impact if we write back too fast. Thus, adjust the
first time write back time to 24 hours which is aligned
with periodic write back time.
Bug: 166739872
Test: boot
Signed-off-by: Martin Liu <liumartin@google.com>
Change-Id: If1398bc44db0619cf2e2be87d4813972c0454dba
Signed-off-by: pix106 <sbordenave@gmail.com>
* Done via the kernel, forgot the line exists in DT as well
Signed-off-by: clarencelol <clarencekuiek@icloud.com>
Signed-off-by: pix106 <sbordenave@gmail.com>
On devices with cellular data available, I've been experiencing Wi-Fi
dropouts on 5 GHz networks where it disconnects and falls back to
cellular data around a RSSI of -77 dBm. While the Wi-Fi quality may not
be ideal at this signal level, it is still better to stay on it than
switch to cellular data because switching networks can be very
disruptive to the user.
To make matters worse, the signal tends to oscillate around -77 dBm in
my case, which causes it to oscillate between Wi-Fi and cellular data
every few seconds. This causes far more disruptions than staying on weak
Wi-Fi would.
These signal levels were measured empirically on a Pixel 5, but they
should apply to most devices. 2.4 GHz values were found to be more or
less accurate, but 5 GHz networks continued to work past the AOSP
thresholds. The iPhone 6s was also content with these signal levels and
still displayed 2 of 3 signal levels at -77 dBm.
Change-Id: I377be8374955530a5f6c084620460cac87e6a126
Signed-off-by: pix106 <sbordenave@gmail.com>
* In settings, it called "extends capatibility"
* packages/apps/Settings/src/com/android/settings/wifi/tether/WifiTetherMaximizeCompatibilityPreferenceController.java#L76 private boolean is5GhzBandSupported();
Signed-off-by: pix106 <sbordenave@gmail.com>
* gSoftApMaxPeers is not set in WCNSS_qcom-cfg.ini
* As kernel define it default 32 in drivers/staging/qcacld-3.0/components/mlme/dispatcher/inc/cfg_mlme_sap.h, make system settings same
Signed-off-by: pix106 <sbordenave@gmail.com>
* Yet another disablement we need, to have bluetooth working properly on A13 (QPR2)
Change-Id: Id3889d6310bac6d417ff2871d5e4a8c513e77354
Signed-off-by: pix106 <sbordenave@gmail.com>
* BOARD_HAVE_BLUETOOTH is uneeded.
* BOARD_HAVE_BLUETOOTH_QCOM is only important if
you build libbt-vendor which we don't.
Change-Id: Ib0465b3c0d5138a70cee6a3c3d5f08dd7ce9aa57
Signed-off-by: pix106 <sbordenave@gmail.com>
[basamaryan: This is needed for Android U to fix RIL]
Signed-off-by: basamaryan <basam.aryan@gmail.com>
Change-Id: Ie3fa610f71077b4ee2af1b4d57bd0c30b34f30fa
Signed-off-by: pix106 <sbordenave@gmail.com>
Mount of tracefs in /sys/kernel/debug/tracing will fail when DEBUG_FS
is disabled. So, mount tracefs in /sys/kernel/tracing to still use all the
tracing abilities when CONFIG_DEBUG_FS is disabled
Change-Id: Ib37332c3f1108d7c4798717f0f009c891db72850
Signed-off-by: pix106 <sbordenave@gmail.com>
