I'm working on an Android project and I am using the NDK to call native methods.
I have two libraries (.so files) and one is located in the libs/armeabi
folder and the other one is located in the libs/armeabi-v7a
lib folder.
If I try to run the application then it won't load the library in the /libs/armeabi
folder. If I move the library file to the libs/armeabi-v7a
folder, then it loads the library but after 5 to 10 minutes it crashes and gives a segmentation fault error.
I was wondering if the location of the library (different folder) might cause this problem.
Within a given architecture type there are multiple versions. armeabi-v7a is the older target, for 32 bit arm cpus, almost all arm devices support this target. arm64-v8a is the more recent 64 bit target (similar to the 32-bit -> 64 bit transition in desktop computers).
o lib/armeabi-v7a is the older target, for 32 bit arm cpus. o lib/arm64-v8a is the more recent 64 bit target. o arm64-v8a devices can run code compiled against armeabi-v7a. o some lib/x86 & lib/x86_64 devices can run code compiled for arm devices. etc.
EABI - Embedded Application Binary Interface. So ARMEABI are compiled binaries matching your android device's CPU architecture.
When installing an application, the package manager service will scan the .apk and look for any shared library of the form:
lib/<primary-abi>/lib<name>.so
If one is found, then it is copied under $APPDIR/lib/lib.so, where $APPDIR corresponds to the application's specific data directory.
If none is found, and a secondary ABI is defined, the service will then scan for shared libraries of the form:
lib/<secondary-abi>/lib<name>.so
If anything is found, then it is copied under $APPDIR/lib/lib.so.
For the primary/secondary abi,
The Android system knows at runtime which ABI(s) it supports. More precisely, up to two build-specific system properties are used to indicate:
the 'primary' ABI for the device, corresponding to the machine code used in the system image itself.
an optional 'secondary' ABI, corresponding to another ABI that is also supported by the system image.
For example, a typical ARMv5TE-based device would only define the primary ABI as 'armeabi' and not define a secondary one.
On the other hand, a typical ARMv7-based device would define the primary ABI to 'armeabi-v7a' and the secondary one to 'armeabi' since it can run application native binaries generated for both of them.
This mechanism ensures that the best machine code for the target device is automatically extracted from the package at installation time.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With