Solve the problem that Android uses a third-party library. so to automatically delete, android. so

Solve the problem that Android uses a third-party library. so to automatically delete, android. so

1. In the new directory prebuilt under the jni directory, the new file Androidusc. mk under this directory (the name can be obtained at will), copy the third-party library. so to this directory

2. Open Androidusc. mk to add the content. For example, the third-party library is libScreenPop. so:

LOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_MODULE := ScreenPopLOCAL_SRC_FILES := libScreenPop.soinclude $(PREBUILT_SHARED_LIBRARY)

3. Modify the Android. mk file in the jni directory and add a statement:

include $(LOCAL_PATH)/prebuilt/Androidusc.mk

Clean Project, complete.

Android cannot find third-party so Library

You need to write an X86 processor library in linux, which should be used in java and under the arm processor.
Does that mean this?
 
How does Android call a third-party SO dynamic link library?

Solution: 1. put the SO file directly under libs/armeabi, and then the code is System. loadLibrary ("xxx"); then publicnativestaticintxxx_xxx_xxx (); then you can directly call the xxx_xxx_xxx () method; 2. the second solution is to create your own SO file, call third-party SO in your SO file, and then call your own SO in the program. This is complicated and requires the creation of java class files, generate. h file, which is generated before the C source file include. h file and implement the corresponding method, and finally use the ndk-build script in the androidNDK Development Kit to generate the corresponding. so shared library; solution: the second solution on the Internet is to reference the so library, and finally claim the JAR ------ solution ---------------------------------------------------- first, check whether this SO is a JNI standard SO, for example, is JNI not directly supported returned? Type. That is to say, can this SO be called directly as JNI. If the answer is no, you can only select the second solution. If the answer is yes, check whether you want the SO library to be directly exposed to the JAVA layer. If the answer is no, you can only select the second solution, for example, you are also a database provider. Generally, if you only have SO, it indicates that this is provided by someone else. You can ask the other party to provide you with a matching JAVA call file. 1. It depends on whether the SO complies with the JNI call specification. It depends on your own wishes. 2. Because the second method is the most flexible, it can be implemented in various situations. 3. You can ------ solution -------------------------------------------------------- the simplest way to check whether the function name in SO is in the Java_XXX_XXX_XXX format, you can write a matching JAVA file by yourself. Pay attention to the conversion rules for SO function names and JAVA function names, or ask the SO provider. If not, select the second method.