这是一个创建于 775 天前的主题，其中的信息可能已经有所发展或是发生改变。
继上次头文件向下兼容后（最终我们采用了宏控的方式来解决这个问题），我们产品经理又给我们带来了难题，在同一个项目中，两个厂家都需要来适配我们定义的借口并提供 lib.so ，在编译时无法区分具体的厂家，只有在程序运行起来时根据配置去解析。
这样意味着我们的软件在打包时需要打包两个 libx.so ，且不能再放到 system/lib64 目录下了（程序运行环境是安卓）
目前为止，我们想到的办法是，将代码里直接调用 libx.so 接口的地方改掉，改为调用函数指针，而这个指针地址通过 dlopen 后拿到的句柄去获取，对于不同的厂家 dlopen 不同路径下的 libx.so 即可。
除了这种方式，我们也想过在程序运行真正前，先执行代码逻辑将 libx. so 拷贝到 system/lib64 目录下，然后调用的地方仍旧保持不变。但实践下来并不成功，原因是 system/lib64 不支持外部拷入。
想问一下大家，这种情况有没有好的解决办法？
这样意味着我们的软件在打包时需要打包两个 libx.so ，且不能再放到 system/lib64 目录下了（程序运行环境是安卓）
目前为止，我们想到的办法是，将代码里直接调用 libx.so 接口的地方改掉，改为调用函数指针，而这个指针地址通过 dlopen 后拿到的句柄去获取，对于不同的厂家 dlopen 不同路径下的 libx.so 即可。
除了这种方式，我们也想过在程序运行真正前，先执行代码逻辑将 libx. so 拷贝到 system/lib64 目录下，然后调用的地方仍旧保持不变。但实践下来并不成功，原因是 system/lib64 不支持外部拷入。
想问一下大家，这种情况有没有好的解决办法？
 |
1
FranzKafka95 OP 另外备注一下，本身我们的进程属于 root 进程，而且 /system/lib64 对于 root 是可读写的，但就是不清楚为什么 cp 执行不成功，脑壳痛
|
 |
2
cppc 2022-03-11 12:48:45 +08:00
一个 so ，两份头文件分别给两家厂商。你这个场景我看着像提供两份特供 SDK ，不是别人来适配你们。。
|
 |
3
jorneyr 2022-03-11 12:51:13 +08:00
so 动态加载
|
|
4
FranzKafka95 OP @cppc 一份头文件，给两个甚至多个厂家，厂家来实现提供 so 库，我们集成厂家的 so 库
|
|
5
FranzKafka95 OP @jorneyr 请问如果实现这个动态加载，除了 dlopen 的这种形式坏还有其他办法吗
|
|
6
cppc 2022-03-11 13:28:12 +08:00
@FranzKafka95 搞半天你才是服务使用方，你自己开发一个代理层，它在根据需求加载同厂家的 so ，把 so 的句柄，和函数指针保存起来，你自己应用不直接调用厂商的 so ，而是通过这个代理来调用。
|
|
7
jorneyr 2022-03-11 13:30:21 +08:00
@FranzKafka95
好像没了，就是 so 的隐式动态加载。 |
|
8
FranzKafka95 OP @cppc 貌似只有这样改了，可是我还是不死心，为什么不能 cp 到 system/lib64 直接以系统加载的方式直接掉接口
|
|
9
cppc 2022-03-11 14:00:24 +08:00
jna 跨平台动态库加载实现是这样的：它加载动态库时，先判断当前环境，然后把 jar 包里面的动态库保存到临时目录，最后再通过绝对路径加载动态库。
都是 java ，可抄 |
|
10
FranzKafka95 OP @cppc 我们是 native C++的应用，你说的这个我知道，最终都是通过 dlopen 动态加载，可现在我就是不想通过 dlopen 加载
|
 |
11
orannge 2022-03-11 23:03:16 +08:00
要是 /system/lib64 改了，系统还怎么做 OTA 升级？这样明显不行
|
Select Language