* 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>
APM would fail to parse the config anyway:
E DevicesFactoryHAL: loadAudioInterface couldn't load audio hw module audio.a2dp (No such file or directory)
W DevicesFactoryHalHidl: The specified device name is not recognized: "a2dp"
E AudioFlinger: loadHwModule() error -22 loading module a2dp
W APM_AudioPolicyManager: could not open HW module a2dp
Change-Id: Iaa1be881cfe8f8474cef0ba46e1b0a62b59e14be
* The keydirectory and metadata_encryption flags for /data make lineage recovery improperly format it
Change-Id: I853b9c94c9bc0d295d393a3e820595ef99593583
And also fix a dumb spelling mistake along the way lol
Change-Id: Ia7930b6ea149777a01eee3e13ff32c5d7234903e
Change-Id: I4fe37450f38c2991e024b7590a579f521136e848
Simon1511