Linux桌面环境下加载运行JNI .so动态库的方案咨询

结论是不行，直接这么试跑不起来。
原因非常直接：

• JNI_OnLoad根本不是给无JVM环境调用的函数，它的签名固定是jint JNI_OnLoad(JavaVM* vm, void* reserved)，第一个参数必须是已经初始化完成的合法JavaVM实例指针，纯C写的程序里根本不存在这个对象，你传空或者伪造指针进去，调用瞬间就会段错误。
• 你手上的x86版so是给安卓编译的，默认会依赖一堆安卓系统原生库，比如liblog、libcutils、libandroid_runtime这些，桌面Linux的动态链接器根本找不到这些依赖，dlopen调用第一步就会返回空，连so都映射不到进程内存里。
• 就算你把所有依赖库都凑齐了，JNI_OnLoad里的常规逻辑——比如注册native方法、查找Java类、获取上下文对象——全要走JNIEnv的接口，这些接口背后全是JVM/ART运行时的实现，没有运行时支撑，逻辑根本走不下去。
• 纯C加载器最多能调用so里完全不碰JNI、不依赖安卓运行时的独立C函数，但凡沾JNI相关的逻辑必崩。

按实现成本从低到高列实际能用的方案：

• 桌面OpenJDK+自定义桩兼容
  别用纯C写加载器，要么用Java写入口，要么用C写加载器先调用JNI_CreateJavaVM在当前进程拉起一个标准OpenJDK的JVM实例，拿到合法的JavaVM和JNIEnv指针之后，再dlopen目标so，dlsym拿到JNI_OnLoad的地址，把JavaVM指针传进去调用。
  提前把so依赖的通用native库放到LD_LIBRARY_PATH路径下，遇到so调用安卓专属API的地方，自己写简单的桩函数替换就行，比如__android_log_print可以直接重定向到桌面的fprintf输出，简单的工具类函数自己补逻辑就行，开发成本很低。
• 桌面安卓兼容层运行
  如果目标so强依赖安卓框架API，自己写桩的工作量太大，直接在Linux桌面装Waydroid或者Anbox这类x86安卓兼容层，把so扔到兼容层的安卓环境里正常加载运行就行，不用自己写加载器，兼容性最好，也不用处理复杂的API适配。
• 移植独立ART运行时
  如果你一定要把so嵌入到自己的独立二进制里，不想要安卓兼容层的额外开销，可以把AOSP里的ART运行时、核心原生系统库单独编译成桌面Linux可链接的静态/动态库，在你的加载器进程里直接初始化ART环境，再加载目标so。这个方案兼容性比OpenJDK加桩好很多，但是编译移植ART的门槛很高，适合对包体积、运行控制权有要求的场景。

实操提醒：如果目标so没有做环境校验、反调试，优先选第一个OpenJDK加桩的方案，最快能跑通；如果so有安卓环境检测逻辑，直接选第二个兼容层方案，省得逆向改so的校验逻辑。

内容的提问来源于stack exchange，提问作者Jiwon