* Due to config_powerDecoupleInteractiveModeFromDisplay we need to wait for the sensors sub HAL to re-start every time we fail a fingerprint unlock with screen off or on AOD.
* To prevent killing said overlay and having the touchscreen constantly enabled on AOD, we simply toggle the touchscreen on/off with every screen-off-UDFPS unlock
Change-Id: I819b9ef4387a914ccf17d7f4c6023ad08b3d14a0
* onFingerUp() would also be called during unlocking with Pin/Password/etc, always resetting the brightness to the previous value
Change-Id: I5319a8a50a4ad3308e787322c6c2a417b9169b23
This reverts commit 787989e7a4.
Test: build, flash and boot device with flag reverted.
Test: boot GSI with compressed APEX enabled.
Change-Id: I5988614cc055d565b17a5c8d830e35feb0e33e92
Signed-off-by: Alexander Martinz <amartinz@shiftphones.com>
* Let framework handle the other ones
* On devices without hardware effects DOUBLE_CLICK effect is just
a single click without this
* Let's only keep CLICK and TICK if no hardware effects are supported,
just like AOSP default vibrator impl
Change-Id: Ib8bf299a417d82fe6196e1b071b5a7b2f9c3e5d8
* Use a script to swap check if we are in an A2DP phone call
* Use an app to check if we are in a VoIP or A2DP call and pass parameters accordingly
* Correctly route A2DP phone calls to the actual bluetooth device instead of earpiece and un-swap speaker and earpiece in VoIP calls
Change-Id: I1de8b2ed57b265b65cf619000e78e290c98e3d5c
Co-Authored-By: Ruchit <ruchitmarathe@gmail.com>
Use 64-bit dex2oat for better dexopt time.
Move it to system.prop
Bug: 153380900
Test: boot and install an application
Change-Id: I3e7a6e6e9385ff6564d1a2e6dda004ebb061f095
(cherry picked from commit 126f03be80f57a8a0411842011152d9381589b78)
Merged-In: I3e7a6e6e9385ff6564d1a2e6dda004ebb061f095
Signed-off-by: Henrique Pereira <hlcpereira@outlook.com.br>
This shouldn't cause adverse effects on devices with less RAM (e.g. 4
GB) as the low memory killer should kick in long before this limit on
such devices
Signed-off-by: HeroBuxx <herobuxx@gmail.com>
Signed-off-by: Ruchit <ruchitmarathe@gmail.com>
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
This prop has no effect as of T QPR1.
See: cf25e33147
Change-Id: Ic762812dd59429d344ccc55c01bf96b0ffd6dbab
Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
ujjwalkirorimal