diff options
author | Christopher R. Palmer <crpalmer@gmail.com> | 2015-12-29 11:11:35 -0500 |
---|---|---|
committer | Gerrit Code Review <gerrit@cyanogenmod.org> | 2016-03-10 17:13:27 -0800 |
commit | 564f10b8f05ddf4d9ea2c0e64f1b113fe6dad4b8 (patch) | |
tree | 15abb71476b559699dde3f2a0c0087fefcd76eca /packages/DocumentsUI/res/values-lv | |
parent | 4718479d82557510c0dc864618af77631c60eb4b (diff) | |
download | frameworks_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