The default camera app can be *huge* in some cases, e.g. when the app in
question is Google Camera. The system will only pin up to the first 80
MiB of the APK file, as well as the first 80 MiB of its odex. There are
several problems with this:
- We could easily end up with 160 MiB of camera app files pinned,
which is a somewhat tall order with the ~5.3 GiB of usable RAM that
we have
- The data that gets pinned may not even be the most critical data for
launching the camera
Disable pinning of the camera app to save precious RAM on this device.
NB: The value has been changed to false instead of removing it entirely
because we need to override the config set by overlays in the prebuilt
vendor image.
Similar to what we did for the camera app, unpin the launcher app from
memory as well. While the default launcher (Launcher3) isn't
particularly big, it doesn't make much sense to pin because the launcher
does not typically load new resources much. Most of its resources should
already be loaded in memory after it starts, so pinning the APK is
redundant.
NB: The value has been changed to false instead of removing it entirely
because we need to override the config set by overlays in the prebuilt
vendor image.
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.
Change-Id: I541709fc771d4b501b56b8555e5e8a04486d0293
apk name and path was changed as seen here
8be4fc80c0
This causes errors in logs since pinner was trying to pin old app.
PinnerService: Could not pin file /system_ext/priv-app/SystemUI/SystemUI.apk
PinnerService: Failed to pin file = /system_ext/priv-app/SystemUI/SystemUI.apk
On low powered, legacy devices, the animations are a bit sluggish. Set the animation scales to 50% to make the UI feel snappier.
Change-Id: I158ca53f12596e5cbd56fc4c35ca54d76d6ae835
* It is only used here and otherwise we end up with an autogenerated
rro for every package that includes SettingsLib
Change-Id: I8cfed8864a7d928707eb209acecd923209e4adf7
*Drop lineage FOD hal
*Uprev fingerprint hal to 2.3
*Update overlays for UDFPS
*Only light up the screen for 100ms when pressed since onHideFODView is in framework now
*Switch to TARGET_SURFACEFLINGER_UDFPS_LIB
Change-Id: Id7e0d9680a5b308d16e0e91ea6678089874e7d9c
There's nothing really that different here when compared to the
common HAL except for the specific DT2W handling, which can simply
be supported as a power feature lib.
Change-Id: I59d039c500c672c50727aa715c256c9f55d98fa4
* Dropped vendor-specific range > 255
from config_screenBrightnessBacklight (stuck at bootanimation
otherwise)
* Dropped the same amount of entries from the end of
config_screenBrightnessNits (otherwise autobrightness
won't work)
Change-Id: I31956340b0ac66b6e9456df46d0b22493ede0d02
Simon1511