vndk: (native:vendor) should not link to libcamera_client (native:platform)

1.0 相似例子
2-21 17:47:30.305 4365 4365 E CamX : [ERROR][UTILS ] camxosutilslinux.cpp:874 LibMap() dlopen: dlopen failed: library “libstdc++.so” not found, on ‘/vendor/lib64/camera/components/com.**.so’

现象: 在高通平台上一直三方算法时三方库需要用到 libstdc++.so ,因为在vendor/{lib}中没有找到改so库,报了如上错误,就会导致在createpipe 中的createnode时失败,
原因: libstdc++.so 没有找到,
解决方案: Android O项目,在相关的Android.mk文件中在LOCAL_SHARED_LIBRARIES := 中添加上libstdc++ 即可链接该库编译.

Android P项目,Android 项目找上诉添加会有如下报错:
vendor/node/***/build/android/Android.mk: error: com.***.node.***(native:vendor) should not link to libstdc++ (native:platform)
原因时Android的LL-VNDK 为了降低vendor和框架的耦合度,删除了libstdc++库,此时不能采用编译添加库的方法去fix此问题,
vendor程序在运行时会根据相关setting先去在vendor/{lib},如果没有找到回去遍历其他我们配置的lib path,因为上述libstdc++是在system/{lib}中的,我们就需要添加此path供程序运行时查找,
添加方法:
在system/core/rootdir/etc/ld.config.txt文件中,在[vendor]子项中添加如下:
namespace.default.search.paths += /system/${LIB}
此处还有其他的namespace, 如 vndk, sphal等,如果设置default没有生效,则上述的相关namespace都配置下,然后采用排除法,确定是哪个namespace能解决问题.

Android P的vndk(供应商开发套件)是为了降低vendor和platform的耦合度,方便后续坐系统升级时不用改动vendor而直接更改system即可,不确定上述修改可能会带来的其他风险,但自我评估风险不大,因为vendor里面的程序运行时会先去遍历vendor/{lib}没有找到才会去遍历其他库.
转自：https://blog.csdn.net/qq_28648425/article/details/85206036 

2.0 vndk介绍
关于vndk的详细介绍可参考: https://source.android.com/devices/architecture/vndk

VNDK concepts

In an ideal Android 8.0 and higher world, framework processes do not load vendor shared libraries, all vendor processes load only vendor shared libraries (and a portion of framework shared libraries), and communications between framework processes and vendor processes are governed by HIDL and hardware binder.

Such a world includes the possibility that stable, public APIs from framework shared libraries might not be sufficient for vendor module developers (although APIs can change between Android releases), requiring that some portion of framework shared libraries be accessible to vendor processes. In addition, as performance requirements can lead to compromises, some response-time-critical HALs must be treated differently.

The following sections detail how VNDK handles framework shared libraries for vendors and Same-Process HALs (SP-HALs).

Framework shared libraries for vendor

framework shared libraries are classified into three sub-categories:

• LL-NDK Libraries are Framework Shared Libraries that are known to be stable. Their developers are committed to maintain their API/ABI stabilities.
  • LL-NDK includes the following libraries: libEGL.so, libGLESv1_CM.so, libGLESv2.so, libGLESv3.so,libandroid_net.so, libc.so, libdl.so, liblog.so, libm.so, libnativewindow.so,libneuralnetworks.so, libsync.so, libvndksupport.so, and libvulkan.so,
• Eligible VNDK Libraries (VNDK) are Framework Shared Libraries that are safe to be copied twice. Framework Modules and Vendor Modules can link with their own copies. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
  • It does not send/receive IPCs to/from the framework.
  • It is not related to ART virtual machine.
  • It does not read/write files/partitions with unstable file formats.
  • It does not have special software license which requires legal reviews.
  • Its code owner does not have objections to vendor usages.
• Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
  • Are considered framework internal implementation details.
  • Must not be accessed by vendor modules.
  • Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
  • Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL (SP-HAL) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded intoFramework Processes. SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP.

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved SP-HALs:

• libGLESv1_CM_${driver}.so
• libGLESv2_${driver}.so
• libGLESv3_${driver}.so
• libEGL_${driver}.so
• vulkan.${driver}.so
• android.hardware.renderscript@1.0-impl.so
• android.hardware.graphics.mapper@2.0-impl.so

The following libraries are VNDK-SP libraries that are accessible by SP-HALs:

• android.hardware.graphics.common@1.0.so
• android.hardware.graphics.mapper@2.0.so
• android.hardware.renderscript@1.0.so (Renderscript)
• libRS_internal.so (Renderscript)
• libbase.so
• libc++.so
• libcutils.so
• libhardware.so
• libhidlbase.so
• libhidltransport.so
• libhwbinder.so
• libion.so
• libutils.so
• libz.so

The following VNDK-SP dependencies (VNDK-SP-Private) are invisible to SP-HALs:

• libRSCpuRef.so (Renderscript)
• libRSDriver.so (Renderscript)
• libbacktrace.so
• libblas.so (Renderscript)
• libbcinfo.so (Renderscript)
• liblzma.so
• libunwind.so

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS):

• libft2.so (Renderscript)
• libmediandk.so (Renderscript)

android.mk转换为android.bp