在我们的 company,我们正在开发一个包含Java和本机部分的Android SDK.我们以AAR格式打包SDK,其中包含所有资源,java类和本机位.根据AAR规范,本机库应放在AAR包内的jni文件夹中.由于当前的gradle插件不支持高级NDK用例,并且由于我们有一个非常成熟的Android.mk文件已经发展了3年,我们通过从gradle任务调用自定义shell脚本来准备AAR.这个shell脚本使用ndk-build命令构建NDK,运行此脚本的任务作为javaCompile任务的依赖项(我们的代码有多种风格,每种风格都有自己的NDK规则,这些规则是从定义文件中预先加载的然后将ndk-build作为命令行参数提供).

最后,当所有内容都被编译时,我们有一个Copy任务,它将本机库复制到build / intermediates / bundles(最终被压缩到AAR中的文件夹)中的jni文件夹中.这工作正常,直到我们更新我们的项目以使用gradle插件v1.5.0.

在v1.5.0中,插件中引入了一个名为Transform API的东西.虽然我们不使用它,但是这个Transform步骤在任务transformNative_libsWithSyncJniLibsForFlavorNameBuildTypeName中对本机lib进行了一些转换,这在我们已经将我们的lib复制到jni文件夹并导致删除jni文件夹中的所有数据之后发生.这最终导致AAR在需要本机方法时不包含本机库和崩溃.

我们通过使用project.tasks [taskName]来获取该任务并确保在我们将libs复制到jni文件夹之前确实发生了这个问题.

然而,有了这个问题,我们开始担心我们是否以及何时将gradle实验插件(目前仅支持NDK的插件)推出实验阶段,并将成为构建NDK代码的标准.

我们尝试了一下实验插件,除了不同的语法(为什么???),它不支持调试本机代码作为库模块的一部分(gdb文件未打包到AAR中,jniDebuggable标志不再存在).

有谁知道这个插件何时会达到一个稳定的API,并准备好在生产版本中使用？我们希望提前计划从调用ndk-build从shellscript到仅使用gradle的NDK构建具有相同的功能奇偶校验(以及从Android Studio免费支持C编辑,这对于当前配置是不可能的,因此我们依赖于different editor for JNI胶水代码).

最佳答案 我没有路线图,但如果你遵循依赖关系,你会发现Android实验插件仍然是实验性的,因为 new Gradle object model仍然是实验性的.我希望Android Studio插件在基础Gradle代码稳定之前不会稳定.

这就是说：虽然语法差异令人沮丧,但它们通常很容易应用.更重要的是,实验插件确实提供了相当好的调试支持.它不使用gdb(它默认使用lldb)并且它不依赖于jniDebuggable标志.您正在寻找这些这一事实让我觉得您对ndk-gdb的工作原理了解很多,并且可能构建了自己的系统,依赖于这些知识.您是否尝试过按Android Studio中的“调试”按钮？如果您的C代码在主项目中,它应该可以正常工作. (不幸的是,似乎在库项目中设置断点有一些问题.)