Repository navigation
Search the installed ABI first in DirectApkSoSource - #155
nico-gonzalez wants to merge 1 commit into
Conversation
DirectApkSoSource built its APK search paths from SysUtil.getSupportedAbis(), so on x86_64 hosts that also run ARM code it could search an ABI the package manager did not install the app for. Put ApplicationInfo.primaryCpuAbi (via SysUtil.getPrimaryAbi) first; the supported ABIs follow as before.
|
Hi @nico-gonzalez! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
|
@cortinico has imported this pull request. If you are a Meta employee, you can view this in D127601450. |
|
Hi @cortinico sorry for the direct tag, any chance of a release soon on some of these PRs looking to address these Android startup crashes? |
Summary: Fixes #154. `DirectApkSoSource` builds its APK search paths from `SysUtil.getSupportedAbis()`. On x86_64 hosts that also run ARM code, the ABI the package manager installed the app for may not come first. It may not be in the list at all. Then SoLoader looks in the wrong `lib/<abi>` folder and throws `SoLoaderDSONotFoundError`. See the issue for the trace and a reproducer. This change searches `ApplicationInfo.primaryCpuAbi` first, read through the existing `SysUtil.getPrimaryAbi` helper (also used for `SoLoader.sPrimaryAbi`). The supported ABIs follow in their current order, and `LinkedHashSet` removes the duplicate. When `primaryCpuAbi` can't be read, `getPrimaryAbi` falls back to `getSupportedAbis()[0]`, so the order is the same as today. On normal devices the installed ABI is already `SUPPORTED_ABIS[0]`, so nothing changes there. X-link: #155 Reviewed By: danjin250 Differential Revision: D127601450 Pulled By: cortinico fbshipit-source-id: 767d05054a5934f3360faa0f574648836fe191a5
|
This has landed in main here 9e8a25c so I'm closing it. @shamilovtim I will try to create a new release in the near future but I don't have a timeline right now |
Fixes #154.
Summary
DirectApkSoSourcebuilds its APK search paths fromSysUtil.getSupportedAbis(). On x86_64 hosts that also run ARM code, the ABI the package manager installed the app for may not come first. It may not be in the list at all. Then SoLoader looks in the wronglib/<abi>folder and throwsSoLoaderDSONotFoundError. See the issue for the trace and a reproducer.This change searches
ApplicationInfo.primaryCpuAbifirst, read through the existingSysUtil.getPrimaryAbihelper (also used forSoLoader.sPrimaryAbi). The supported ABIs follow in their current order, andLinkedHashSetremoves the duplicate.When
primaryCpuAbican't be read,getPrimaryAbifalls back togetSupportedAbis()[0], so the order is the same as today. On normal devices the installed ABI is alreadySUPPORTED_ABIS[0], so nothing changes there.Test Plan
java/compiles withjavacagainstandroid-36/android.jarand jsr305.SoLoaderDirectApkTest. The OSS tree has no tests. A case next totestPreferredAbiOrder()should check thatgetDirectApkLdPathsstarts with<apk>!/lib/<primaryCpuAbi>when it differs fromSUPPORTED_ABIS[0].SoLoader.init, launches normally on an API 34 x86_64 emulator. This patched SoLoader build has not been run on a device.