Android兼容之libc++_shared.so库冲突方案

小码奔腾ing

已于 2022-12-28 11:16:12 修改

阅读量8.3k

点赞数 1

分类专栏： Android兼容文章标签： android c++

于 2022-12-28 11:13:25 首次发布

奔腾的小马

本文链接：https://blog.csdn.net/ixiaoma/article/details/128465070

版权

Android兼容专栏收录该内容

5 篇文章 0 订阅

订阅专栏

提供解决libc++_shared.so库冲突方案

背景

随着App功能增多，集成的so库也会增多，如果系统中多个so库都使用系统自动生成的libc++_shared.so库，如果不兼容时，会导致某个服务调用时crash

说明
当存在不兼容问题时，app会在掉用服务时，相关页面会停留一小段时间，但是由于so库出现问题，导致crash；可以通过日志查看，里面没有业务的相关代码，只有libc相关信息

--------- beginning of crash
12-28 10:08:58.384 F/libc    ( 9577): Fatal signal 11 (SIGSEGV), code 0 (SI_USER) in tid 9577 (********), pid 9577 (*******)

******

12-28 10:08:59.547 F/DEBUG   (11198): Build fingerprint: 'OPPO/PEAM00/OP4E6B:12/SP1A.210812.016/Q.202210080444:user/release-keys'
12-28 10:08:59.548 F/DEBUG   (11198): Revision: '0'
12-28 10:08:59.548 F/DEBUG   (11198): ABI: 'arm'
12-28 10:08:59.548 F/DEBUG   (11198): Timestamp: 2022-12-28 10:08:58.606402783+0800
12-28 10:08:59.548 F/DEBUG   (11198): Process uptime: 0s
12-28 10:08:59.548 F/DEBUG   (11198): Cmdline: *******
12-28 10:08:59.548 F/DEBUG   (11198): pid: 9577, tid: 9577, name: *******>>> ******* <<<
12-28 10:08:59.548 F/DEBUG   (11198): uid: 11574
12-28 10:08:59.548 F/DEBUG   (11198): signal 11 (SIGSEGV), code 0 (SI_USER), fault addr --------
12-28 10:08:59.548 F/DEBUG   (11198):     r0  fffffffc  r1  fff96b30  r2  00000010  r3  0000037f
12-28 10:08:59.548 F/DEBUG   (11198):     r4  00000000  r5  00000008  r6  ee4ad110  r7  0000015a
12-28 10:08:59.548 F/DEBUG   (11198):     r8  ee4ad15c  r9  ee4ad110  r10 00000000  r11 0000037f
12-28 10:08:59.548 F/DEBUG   (11198):     ip  fff96ae0  sp  fff96ad0  lr  e91a553d  pc  e91d3e08
12-28 10:08:59.548 F/DEBUG   (11198): backtrace:
12-28 10:08:59.548 F/DEBUG   (11198):       #00 pc 00090e08  /apex/com.android.runtime/lib/bionic/libc.so (__epoll_pwait+20) (BuildId: 31468457402d45f9c2aec801ea9152dd)
12-28 10:08:59.548 F/DEBUG   (11198):       #01 pc 00062539  /apex/com.android.runtime/lib/bionic/libc.so (epoll_wait+16) (BuildId: 31468457402d45f9c2aec801ea9152dd)
12-28 10:08:59.548 F/DEBUG   (11198):       #02 pc 000100a5  /system/lib/libutils.so (android::Looper::pollInner(int)+124) (BuildId: 32b80ccb1972fc1d4674ac2cb7671100)
12-28 10:08:59.548 F/DEBUG   (11198):       #03 pc 0000ffcf  /system/lib/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+62) (BuildId: 32b80ccb1972fc1d4674ac2cb7671100)
12-28 10:08:59.548 F/DEBUG   (11198):       #04 pc 000e1be3  /system/lib/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long long, int)+24) (BuildId: ac5eb70d72ef020bce9c91883d2c5cc8)
12-28 10:08:59.548 F/DEBUG   (11198):       #05 pc 001a22ad  /system/framework/arm/boot-framework.oat (art_jni_trampoline+60) (BuildId: 46403c81c600e240f6c59c29cac13fa086bd1cfe)

关键字查询：backtrace 或者 beginning of crash

原因：

不同的libc++_shared.so库不兼容。怎么产生的不兼容呢？libc++_shared.so是c++的标准模板库，从ndk18开始成为android唯一支持的标准模板库。每一个NDK版本都会带有它，在用到它(build.gradle中配置了arguments “-DANDROID_STL=shared”)的时候，就会输出产物中带有libc++_shared.so这个共享库；它源自NDK的目录中，可以从c++的build log中发现路径，
请添加图片描述

"stlSharedObjectMap": {
        "LIBCXX_SHARED": {
          "ARMEABI_V7A": "/Users/dxm/Library/Android/sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/arm-linux-androideabi/libc++_shared.so",
          "ARM64_V8A": "/Users/dxm/Library/Android/sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so",
          "X86": "/Users/dxm/Library/Android/sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/i686-linux-android/libc++_shared.so",
          "X86_64": "/Users/dxm/Library/Android/sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/x86_64-linux-android/libc++_shared.so"
        },
        "LIBCXX_STATIC": {},
        "NONE": {},
        "SYSTEM": {}
      }

每个NDK版本中的libc++_shared.so可能都有变化，前后版本不一定完全兼容。
另外libc++_shared.so是经过strip的，最后包含的符号表也不相同。
stl库有四种包含方式 none|system|shared|static.
这几个原因导致最后的so文件会不兼容。

方案

1、充分沟通协调，所有的提供方都遵循相同的规则，使用统一的ndk版本，最终达到一致。这个方案很彻底，但成本很高，对不同的场合也不一定都实用。
2、作为sdk的提供方(业务提供方)，我们管不了别人，管自己是可以的，我们不出问题，确保我们提供的so不会有冲突也是一种方法。

SDK采用第二种方法也可以，具体方法如下：
1、在我们的c++代码中不要使用stl库中的东西，比如std:map等。
2、在c++代码中不要使用new/delete生成和释放对象，取而代之的是malloc(calloc/realloc)/free来管理对象。
3、在gradle脚本中配置arguments “-DANDROID_STL=none”
这样我们生成的产物就不带有libc++_shared.so文件了，
另外建议：多次尝试兼容，如果不行就让某个业务so库包含libc++_shared.so

参考文档：C++库支持