Home » Android » unsatisfiedlinkerror – android .so files not getting extracted in /data/data/<package>/lib

unsatisfiedlinkerror – android .so files not getting extracted in /data/data/<package>/lib

Posted by: admin June 15, 2020 Leave a comment


I am developing a native android application and using an open source library with .so file generated. Facing a strange behavior.
For the first few times, the application worked perfectly well, with the library getting loaded. But now its not able to find the library and gives –

java.lang.UnsatisfiedLinkError: Couldn’t load : findLibrary
returned null

.Below are few observations: 1. when I extract the .apk file, the library (.so) is present under “lib/armeabi” folder. 2. but when I try to search the library (.so) into the devices extracted path of

, its not present. Any suggestions as to why this strange behavior is happening and why the .so file is not getting extracted under /data/data/com.ibm.homeScreen/lib/ folder.

Thanks in advance!

How to&Answers:

If you use eclipse, check the buildpath settings:
Right click on your project –> Properties –> JavaBuildPath –> Order and Export (is a Tab) and check there if the librar has been marked (checkbox) to export.
There is also a possibility to set the native library path. You can find that option in the Library Tab –> Android Private Libraries –> EDIT Button on the right

This could also help


For eclipse project, simply put all your *.so files inside armeabi or armeabi-v7a folder, and put the folder inside /libs folder in your project. Compile, the *.so files will automatically be imported into /data/data//lib

For Android studio, the above approach didn’t work for me. instead I have to place the armeabi and armeabi-v7a folders into /jniLibs instead of /libs. Note that I am using Gradle 0.10.+ though, not sure if it works on older Gradle.

enter image description here


You can find some further information about this problem here:
Why do some Android phones cause our app to throw an java.lang.UnsatisfiedLinkError?

The stackoverflow link also contains some code with a workaround in the (currently) last answer.