1：当程序报错：
Caused by: java.lang.UnsatisfiedLinkError:com.android.tools.fd.runtime.IncrementalClassLoader$DelegateClassLoader[DexPathList
Most of the reason is that the so file is not loaded normally
2: Find out the reason:
First judge whether you forgot to copy the corresponding so file to the corresponding JNI directory
Find out the mobile phone cpu architecture, go to the corresponding JNI directory to see if there is a corresponding so file
3: Solution:
1) Copy the corresponding so file to the corresponding JNI architecture directory
2) If there are only so files of some of these architectures, but the architecture of the mobile phone does not belong to them, you can set this in the project:
android {
defaultConfig {
ndk {
// 设置支持的 SO 库构架，注意这里要根据你的实际情况来设置 abiFilters 'armeabi'// 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64', 'mips', 'mips64'
}
}
} If Android Studio displays the following information after you add "abiFilter":
NDK Integration IS deprecated in the Consider Trying plugin at The Current at The Experimental new new plugin.
Add gradle.properties file in the project root directory:
android.useDeprecatedNdk = to true
Note that: This method corresponds to a 64-bit architecture mobile phone, but only 32-bit so files are more effective. For knowledge of the architecture, please refer to Baidu's instructions
64-bit (arm64-v8a) mobile phones can run 32-bit (armeabi armeabi-v7a) so files
(Two) android studio loads so files and errors. android java.lang.UnsatisfiedLinkError: Analysis and solutions
The .so library is placed in the corresponding CPU architecture directory under libs/ of the main module, such as libs/armeabi.
In the build.gradle file of the main module, add in the android tag:
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}Then there is an error:
android java.lang.UnsatisfiedLinkError: analysis and solutions"
One, jni has not been compiled yet, it is used while compiling
This can be divided into two cases: the
first is unsatisfiedlinkerror: dll name. Explain that the dll is not placed in the proper position. For android development, we generally put so in the libs directory, but this error still occurs. The root cause is that the system.loadlibrary function will load the so you specify. All the symbols in the so that need to be linked must be able to be linked to. If one link fails, the entire so will also fail to load. Carefully check all the symbols needed in the so to make sure they are present and in the correct positions.
The second is unsatisfiedlinkerror: method name. The dll has been successfully loaded, but the method name is wrong. The most common and basic solution to this error is to carefully compare the prototype of your native method to ensure that it is consistent with the prototype generated by javah. To modify the name of the native method on the java side, you must remember to update the function name on the c/c++ side. This is the most common cause of such errors.
Second, it is jni has compiled compiled library directly with other people so
you build the project put loadlibrary () of class to the package name and class name loadlibrary () where the original project to compile jni time should be consistent, because jni seems to be based on The java package name is named, so it is ok to change it to a consistent name
(C) Android studio java.lang.UnsatisfiedLinkError .so file failed to load solutions to
the problem: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader [DexPathList [[ zip file "/data/app/com.example.demozd-1/ base.apk"],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]] couldn't find "libmsc.so"
Obviously it was caused by not being able to find the .so file when the program was running.
Solution:
1. Make sure there is indeed a .so file in your project. If the error is the same as mine, you can’t find lib64 Barabara, you must also make sure that there is arm64-v8a in your project. If not, create one, and then Copy the .so file in armeabi;
2. If you put all the .so folders under libs, you need to add the following code in the android braces in your build.gradle file:
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
} 3. If all your .so folders are under jniLibs, then make sure that your jniLibs folder is under the src/main/ path, not at the same level as src.
Let's make an explanation from the third-party library ring letter
Some third-party libraries are just a simple jar package, but some are developed using jni, so they will include the so library file. If there is no message at this time, we will encounter an error: java.lang.UnsatisfiedLinkError;
by using the ring letter SDK When this error occurs; here to share the cause of the problem and the solution;
I need to explain the related information here
. The instruction set type provided by hyphenatechatsdk only provides armeabi-v7a, arm64-v8a, and x86;
armeabi and armeabi-v7a are similar instruction sets, v7a is an enhanced instruction set, operating speed, efficiency They are all 32-bit instructions and compatible; arm64-v8a corresponds to the arm64-bit instruction set;
arm64-bit strategy is different from intel IA32: Intel64-bit instructions are compatible with intel32-bit instructions, and programs compiled with intel32-bit instructions can be directly compiled It runs on an intel64-bit machine; but arm is not, arm64-bit and arm32-bit are independent instruction systems and are not compatible; the reason for the design of arm is because it runs on embedded systems, the design indicators tend to be more efficient and power consumption considerations ; In fact, the arm64-bit chip contains both the arm64 instruction processor and the arm32-bit instruction processor, but the two processors are independent of each other;
UnsatisfiedLinkError lead to several reasons
affect link constraints: armeabi can actually run on arm64 bit machines, but Google adds restrictions:
- Android4.x can run as long as it can find so, so can be in armeabi, armeabi-v7a, arm64-v8a, so location can be very arbitrary;
- Starting from Android5.x, the inspection is more stringent, and only the so in the directory corresponding to the chip model will be installed on the phone;
for example: the
directory structure in the development environment is as follows:
libs/armeabi:libhyphenate.so libhyphenate_av.so
libs/armeabi-v7a:
The instruction set corresponding to libmediadata.so mobile phone is armeabi-v7a, and then only libmediadata.so is installed on the mobile phone; - Under Android6.x, the inspection is more stringent. There is a rule that was encountered in the previous test, but I
am not sure now; libs/armeabi/: libhyphenate.so libhyphenate_av.so
libs/arm64-v8a (there is no such directory)
on arm64-bit machines It can also be run, but as a developer, you usually rely on other development packages, such as baiduMap, and also use other so. You cannot let all developers delete the libs/arm64-v8a directory; but developers can try to delete arm64-v8a , Only armeabi is left, so that the installation package will be small and can run on various platforms;
Google’s consideration is the execution rate and a smoother user experience. As a developer and service provider, we hope that the apk is as small as possible for execution The speed requirement is not high; - Armeabi and armeabi-v7a are interchangeable. Few mobile phones on the market now have armeabi, which are basically armeabi-v7a or arm64-bit high-end machines.
- Check the mobile phone chip model: cat /proc/cpuinfo, take a closer look at the printed information, and you can see whether the mobile phone instruction set is 32-bit or 64-bit.
- The x86 directory usually corresponds to a virtual machine. Many developers like to develop and debug on genymotion. This corresponds to 86. x86 is the same as the intel IA32 mentioned above, so only 32-bit is provided, and it can also be used on x86-64-bit machines. Run on
- Our so also depends on libsqlite.so, but because this package has never changed, it uses the default /system/lib provided by the system, which can run on Android 6.x and below platforms, and Android 7.x implements stricter security Check, it is forbidden to use the contents of the system catalog, so if you want to use Android7.x or higher, you need to copy the libsqlite.so of the system catalog and put it in the corresponding instruction directory of your app, because there are no models on the Android7.x market. , So it is not currently under consideration;
- Mobile phones with mips instruction set are rare. I heard that Lenovo has one, but never seen it;
- libs/armeabi/libhyphenate.so and libs.without.audio/armeabi/libhyphenate.so are different, libs/armeabi/libhyphenate.so will depend on libs/armeabi/libhyphenate_av.so, if not found, it will report java.lang. UnsatisfiedLinkError;
- There is another point that is easier to overlook. Now our projects generally introduce multiple third-party libraries. The sixth point also mentions the use of baiduMap, that is, when a project introduces multiple libraries, different libraries have different folder so that when one of the support is relatively small, but another whole comparison, would such a mistake, the solution is not supported so the folder to delete
For example:
instruction set supported ring letter arm64-v8a, armeabi-v7a, x86
Baidu map supports the instruction set arm64-v8a, armeabi, armeabi-v7a, x86, x86_64, mips, mips64
if you want to run on all devices, you need to delete x86_64, mips, mips64;
according to the previous It is said that you can keep the armeabi and armeabi-v7a folders, and then copy the so file in armeabi-v7a to armeabi.
Finally, as long as you carefully look at the ide log prompt, it is easy to solve.