After being abused by React Native for 2 days, write down the c++_share.so conflict handling process

Antecedents feed

In order to cope with the support of the react-Native client, the React-Native plug-in needs to be developed for the client to use. The react native plugin can be developed as follows:

• Reactnative. Cn/docs/native…
• Reactnative. Cn/docs/native…
• Reactnative. Cn/docs/native…
• Reactnative. Cn/docs/native…

It contains two parts

1. ViewManager: Wraps native views for use by the React-native JS portion
2. NativeModule: Provides native API capabilities for react-native JS parts to call

journey

Following the official example, the plug-in code was quickly completed. After happily Posting the plugin to Github, I tried it out and ran into my first problem

So: libc++_shared.so: libc++_shared.so: libc++_shared.so: libc++_shared.so: libc++_shared.so To resolve the conflict, add the following configuration to the Android domain:

packagingOptions {
    pickFirst 'lib/arm64-v8a/libc++_shared.so'
    pickFirst 'lib/armeabi-v7a/libc++_shared.so'
    pickFirst 'lib/x86/libc++_shared.so'
    pickFirst 'lib/x86_64/libc++_shared.so'
}
Copy the code

PackagingOptions: This section explains the meanings and functions of several keywords in the package options

The way to handle this is to get the first libc++_shared.so if there is a conflict. After the conflict is resolved, it continues to run. After opening the camera for a while, it crashes with the following error:

com.awesomeproject A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 30755 (work), pid 30611 (.awesomeproject)
Copy the code

From the error message, we only know that the error is in the JNI part, where is the specific location? What line of code? I don’t know. From the phenomenon, we can roughly guess the wrong entry, so we tried it line by line. Finally, we found that the code reporting the error was:

std::cout << "src: (" << h << ", " << w << ")" << std::endl;
Copy the code

A simple c++ output stream would have no effect on the functionality. Curious as to why the crash happened. Nothing. Since it does not affect the function of the first deleted this line of code, and indeed did not report errors, functions can be used normally, happy to test regression. Everything was fine until I ran on the ARM64-V8A device and received the following error:

The _sfp_handler_exception function is missing when running opencv_java3.so, which is actually in the c++_shared.so library. Oddly enough, native code runs well on ARM64-V8A devices, but it lacks the _sfp_handler_exception function when running in react-native environments. It wasn’t until I compiled natively with NDK20A and reported the same error that I realized the source of all the problems was pickFirst.

It is obvious that the size of c++_shared.so in apk packages from react-native and native environments is different. For example, if two c++_shared.so files are printed with different NDK versions, the internal library functions are not the same, and pickFirst selects the first one and the other libraries will not be compatible. Merge two c++_shared.so If our SDK had only one library that was dynamically dependent on c++_shared.so, we could have used c++_shared.so as a static library. The configuration is as follows:

externalNativeBuild { ndk { abiFilters "armeabi-v7a", "Arm64-v8a"} cmake {cppFlags "-std=c++ 11-frtti -fexceptions" arguments "-dandroid_stl =c++_shared" }Copy the code

Unfortunately, the example SDK has more than one library that dynamically relies on c++_shared.so, so this route doesn’t work either. So we can only start from the React-Native side to find solutions.

Option 1 (Recommended)

Find out what NDK version of c++_shared.so is based on in the react-native side, and try to keep the NDK versions consistent.

The react-Native android project is probably based on the NDK R20B. The next step is to change the NDK version of the SDK based on c++_shared.so.

1. Recompile opencV library based on NDK R20B
2. Connect the OpencV library to the project and recompile the Alive_detected. So library based on NDK R20b

Re-import the compiled SDK plug-in upgrade, and all the problems were solved after running.

Scheme 2

In addition to the c++_shared.so library in react-native, react-native did not initially introduce c++_shared.so. There is no c++_shared.so library in the React Native version before 0.59.

The react-Native version can also be downgraded to 0.59 or lower. The steps are as follows:

1. Into the project

cd Temple
Copy the code

2. Specify the version

NPM install - save [email protected]Copy the code

3. update

react-native upgrade
Copy the code

4. Replace files all the way

conclusion

Android development will face a variety of environmental problems, problems should be based on principles, clear the root of the problem, so that the problem is easy to solve.