blocks|key|181064|text|正确的构建过程相对简单，我的问题是使libmod1.so依赖于libmod2.so在启动时导致不满意的链接-+mod1代码无法找到mod2共享库，即使两者都存在于最终APK中的同一文件夹中，位于libs/armeabi、libs/x86等下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|181065|181066|将你的C或C%2B%2B源代码和头文件放在你的安卓项目的jni目录子目录下，例如mod1/和mod2/|unordered-list-item|181067|文件夹，按照NDK的说明创建Application.mk文件，例如我的是：|181068|181069|181070|+NDK_TOOLCHAIN_VERSION=4.7|blockquote|181071|181072|APP_PLATFORM+:=安卓-8|181073|APP_ABI+:=+armeabi+armeabi-v7a+x86|181074|181075|181076|遵循以下模板创建Android.mk：|181077|181078|181079|+LOCAL_PATH目录$(调用my-+:=+)|181080|181081|包含$(CLEAR_VARS)|181082|LOCAL_SHARED_LIBRARIES+:=+mod2   #这使得libmod1.so依赖于libmod2.so|181083|LOCAL_MODULE+:=+mod1|181084|LOCAL_SRC_FILES+:=+mod1/file1.c|181085|LOCAL_SRC_FILES+%2B=+mod1/file2.cpp|181086|..。|181087|包含$(BUILD_SHARED_LIBRARY)   #这实际上构建了libmod1.so包含$(CLEAR_VARS)|181088|LOCAL_MODULE+:=+mod2|181089|LOCAL_SRC_FILES+:=+mod2/file1.cc|181090|LOCAL_SRC_FILES+%2B=+mod2/file2.cc|181091|181092|包含$(BUILD_SHARED_LIBRARY)   #这将构建libmod2.so|181093|就是这样，所有的构建都使用了ndkbuild脚本。您只需要一个C包装器来调用Java中的一些函数。这就是我的问题。由于我只有在libmod1.so中才有可从Java调用的函数，所以我的Java+C包装器类如下所示：|181094|public+class+CWrapper+{
++++static+{
++++++++System.loadLibrary("mod1");
++++}
++++public+static+native+int+func1(String+aParam);
++++...
}|code-block|syntax|javascript|181095|这对我来说似乎是非常合乎逻辑的-我从Java调用libmod1.so，所以我使用了System.loadLibrary("mod1")，既然libmod1.so知道它依赖于libmod2.so，而且两个文件都在同一个文件夹中，libmod1应该知道如何查找和加载libmod2，对吧？不对!它在应用程序启动时崩溃，并带有“不满意的链接”。确切的错误消息是：|181096|java.lang.UnsatisfiedLinkError:+Cannot+load+library:+soinfo_link_image(linker.cpp:1635):+could+not+load+library+"libmod2.so"+needed+by+"libmod1.so";+caused+by+load_library(linker.cpp:745):+library+"libmod2.so"+not+found|181097|我到处寻找更多的代码来添加到Android.mk中，以解决这个问题，但没有成功。终于有了Eureka！我修改了CWrapper类，如下所示：|181098|public+class+CWrapper+{
++++static+{
++++++++System.loadLibrary("mod2");+//+must+be+first,+as+mod1+depends+on+mod2!
++++++++System.loadLibrary("mod1");
++++}
++++public+static+native+int+func1(String+aParam);
++++...
}|181099|事情开始变得像魔咒一样有效。|181100|格雷格|181101|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|28|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|29|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|2A|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|2B|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|2E|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2G|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|2H|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|2I|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|2K|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]|$1|X|3|Y|5|L|7|2N|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|2O|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2P|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|2R|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2S|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2T|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2U|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2V|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2W|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2X|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|1K|3|1B|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|30|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|31|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|1R|7|32|8|@]|9|@]|A|$1S|1T]]|$1|1U|3|1V|5|6|7|33|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|1R|7|34|8|@]|9|@]|A|$1S|1T]]|$1|1Y|3|1Z|5|6|7|35|8|@]|9|@]|A|$]]|$1|20|3|21|5|1R|7|36|8|@]|9|@]|A|$1S|1T]]|$1|22|3|23|5|6|7|37|8|@]|9|@]|A|$]]|$1|24|3|25|5|6|7|38|8|@]|9|@]|A|$]]|$1|26|3|-4|5|6|7|39|8|@]|9|@]|A|$]]]|27|$]]

The correct build procedure was relatively easy, my problem was that making libmod1.so dependent on libmod2.so caused unsatisfied links upon startup - mod1 code could not find mod2 shared library, even though both were present within the same folder in the final APK, under libs/armeabi, libs/x86 etc. However, to make my answer complete:

<ul>
<li>Put your C or C++ sources and header files under sub-directories of jni dir in your Android project, e.g. folders mod1/ and mod2/</li>
<li>Per NDK instructions, create Application.mk file, e.g. mine is:</li>
</ul>

<blockquote>
 NDK_TOOLCHAIN_VERSION=4.7 
 APP_PLATFORM := android-8 
 APP_ABI := armeabi armeabi-v7a x86
</blockquote>

<ul>
<li>Create Android.mk following this template:</li>
</ul>

<blockquote>
 LOCAL_PATH := $(call my-dir) 
 include $(CLEAR_VARS) 
 LOCAL_SHARED_LIBRARIES := mod2 &nbsp;&nbsp;&nbsp;# this makes libmod1.so dependent on libmod2.so 
 LOCAL_MODULE := mod1 
 LOCAL_SRC_FILES := mod1/file1.c 
 LOCAL_SRC_FILES += mod1/file2.cpp 
 ... 
 include $(BUILD_SHARED_LIBRARY) &nbsp;&nbsp;&nbsp;# this actually builds libmod1.so 
 
 include $(CLEAR_VARS) 
 LOCAL_MODULE := mod2 
 LOCAL_SRC_FILES := mod2/file1.cc 
 LOCAL_SRC_FILES += mod2/file2.cc 
 ... 
 include $(BUILD_SHARED_LIBRARY) &nbsp;&nbsp;&nbsp;# this builds libmod2.so 
</blockquote>

That's about it, all builds without complains with ndkbuild script. You only need a C wrapper to call some functions from Java. And here was my problem. Since I had functions callable from Java only in libmod1.so, my C wrapper class in Java was like:

<pre><code>public class CWrapper {
 static {
 System.loadLibrary("mod1");
 }
 public static native int func1(String aParam);
 ...
}
</code></pre>

This seemed perfectly logical to me - I call to libmod1.so from Java, so I used System.loadLibrary("mod1"), and since libmod1.so knows it depends on libmod2.so, and both files are in the same folder, libmod1 will know how to find and load libmod2, right? Wrong! It was crashing upon app startup with "unsatisfied link". The exact error message was:

<pre><code>java.lang.UnsatisfiedLinkError: Cannot load library: soinfo_link_image(linker.cpp:1635): could not load library "libmod2.so" needed by "libmod1.so"; caused by load_library(linker.cpp:745): library "libmod2.so" not found
</code></pre>

I was searching everywhere for some more code to add to Android.mk to resolve this in vain. Finally Eureka! I modified my CWrapper class as follows:

<pre><code>public class CWrapper {
 static {
 System.loadLibrary("mod2"); // must be first, as mod1 depends on mod2!
 System.loadLibrary("mod1");
 }
 public static native int func1(String aParam);
 ...
}
</code></pre>

and things started working like a charm...

Greg

Wasted half a day trying to build two shared libraries, e.g. <code>mod1</code> and <code>mod2</code> (which Android NDK compiles to <code>libmod1.so</code> and <code>libmod2.so</code>), from sources in a jni folder and sub-folders, then have mod1 call a function from mod2. Plenty of answers on how to make the build work, but then runtime dynamic linking was not working, the app crashed on startup.

Decided to post this question and immediately answer it, so that Q and A to the whole process are together, and hopefully someone else won't waste a day researching it again.

Android NDK - make two native shared libraries calling each other

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我花了半天的时间尝试从jni文件夹和子文件夹中的源代码构建两个共享库，例如mod1和mod2 ( Android NDK将其编译为libmod1.so和libmod2.so)，然后让mod1调用mod2中的函数。有很多关于如何使构建工作的答案，但随后运行时动态链接不起作用，应用程序在启动时崩溃。我决定发布这个问题并立即...

Android NDK -使两个本机共享库相互调用-腾讯云开发者社区-腾讯云

问Android NDK -使两个本机共享库相互调用
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Android NDK -使两个本机共享库相互调用EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Android NDK -使两个本机共享库相互调用
EN