The support 64-bit architectures guide provides a command for selecting which ABI libraries to use during the APK installation process:
# A successful install:
$ adb install --abi armeabi-v7a APK_FILE.apk
Success
This command can be handy when your APK includes several ABI libraries, your CPU able to run multiple ABIs and you want to explicitly specify which ABI to use.
For example, my Pixel XL device supports the following ABIs (both 32 and 64 bits):
# 32-bit ABIs, mapped to Build#SUPPORTED_32_BIT_ABIS
$ adb shell getprop ro.product.cpu.abilist32
armeabi-v7a,armeabi
# 64-bit ABIs, mapped to Build#SUPPORTED_64_BIT_ABIS
$ adb shell getprop ro.product.cpu.abilist64
arm64-v8a
Once I've built my APK with arm64-v8a ABI support (along with armeabi-v7a libraries), I can specify which ABI I'd like to use using:
$ adb install --abi arm64-v8a APK_FILE.apk
Those who would like to verify that the 64-bit library was indeed loaded at runtime - can check the dynamic linker's debug logs. Support for printing those logs was added in this commit, and available since Oreo (version 8.0). Note that this only works for APKs built in debug mode. Device rooting is not required.
To enable the ld debug logs for a particular app, use:
$ adb shell setprop debug.ld.app.com.example.myapp dlerror,dlopenwhere:
- com.example.myapp is your package name.
- dlerror,dlopen are the filtering options. Any combination of dlerror (enables logging of all dlerrors) / dlopen (traces dlopen and dlclose calls) / dlsym (symbols resolution) is being supported.
Example for such use (package name = info.osom.nativesandbox):
$ adb shell setprop debug.ld.app.info.osom.nativesandbox dlerror,dlopen
Verifying the property was set:
$ adb shell getprop debug.ld.app.info.osom.nativesandbox
dlerror,dlopen
Now let's run adb logcat and start the app:
D/linker: dlopen(name="/data/app/info.osom.nativesandbox-_1cbjYwj8FtK4-Mjp4m-Sw==/lib/arm64/libnative-lib.so", flags=0x2, extinfo=[flags=0x200, reserved_addr=0x0, reserved_size=0x7b6ed1a400, relro_fd=1857095400, library_fd=123, library_fd_offset=0x7ff8f34868, library_namespace=classloader-namespace@0x7bf45e0210], caller="/system/lib64/libnativeloader.so", caller_ns=(default)@0x7bf4775438) ...
D/linker: ... dlopen calling constructors: realpath="/data/app/info.osom.nativesandbox-_1cbjYwj8FtK4-Mjp4m-Sw==/lib/arm64/libnative-lib.so", soname="libnative-lib.so", handle=0x99a17691a1a513e1
D/linker: ... dlopen successful: realpath="/data/app/info.osom.nativesandbox-_1cbjYwj8FtK4-Mjp4m-Sw==/lib/arm64/libnative-lib.so", soname="libnative-lib.so", handle=0x99a17691a1a513e1
D/linker: dlerror set to "undefined symbol: JNI_OnLoad"
From the above debug logs we can see that dynamic linker loaded the native library from the arm64 folder.
No comments:
Post a Comment