summaryrefslogtreecommitdiffstats
path: root/packages/DocumentsUI/res/values-lv
diff options
context:
space:
mode:
authorChristopher R. Palmer <crpalmer@gmail.com>2015-12-29 11:11:35 -0500
committerGerrit Code Review <gerrit@cyanogenmod.org>2016-03-10 17:13:27 -0800
commit564f10b8f05ddf4d9ea2c0e64f1b113fe6dad4b8 (patch)
tree15abb71476b559699dde3f2a0c0087fefcd76eca /packages/DocumentsUI/res/values-lv
parent4718479d82557510c0dc864618af77631c60eb4b (diff)
downloadframeworks_base-564f10b8f05ddf4d9ea2c0e64f1b113fe6dad4b8.zip
frameworks_base-564f10b8f05ddf4d9ea2c0e64f1b113fe6dad4b8.tar.gz
frameworks_base-564f10b8f05ddf4d9ea2c0e64f1b113fe6dad4b8.tar.bz2
intel: Pick the best ABI based on number of libs, not just priority
The normal package loading will open the APK and find the highest priority ABI that contains one or more native libraries. This works well for 64-bit vs. 32-bit but doesn't work very well for ARM vs. Intel ABIs. There are many broken apps in the market which fail to run when installed as x86. I believe that there are so many apps because an app that doesn't itself have native x86 libs but imports a 3rd party lib that does support x86 will end up installin the x86 libs for the support library which fools the package installer. As a simple heuristic, pick the ABI that contains the most shared libraries. That works around the common case of missing the app's own shared libraries. Note: the consequences of picking incorrectly are actually quite small since the app should still run, although it will run less efficiently because it is emulated. Note: if two ABIs have the same number of libs, we pick the higher priority one as a tie-breaker. Change-Id: Ie4880810f46875869ce054b3c46acac64b953996
Diffstat (limited to 'packages/DocumentsUI/res/values-lv')
0 files changed, 0 insertions, 0 deletions