在我们的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 plugin v1.5.0。
在v1.5.0中，插件中引入了一个名为Transform API的东西。虽然我们不使用它，但是这个转换步骤会对任务 transformNative_libsWithSyncJniLibsForFlavorNameBuildTypeName 中的本机库进行一些转换，这在我们已经将我们的库复制到jni文件夹并导致删除jni文件夹中的所有数据之后发生。最终结果是AAR在需要本机方法时不包含本机库和崩溃。
我们通过使用project.tasks[taskName]来获取该任务并确保在我们将libs复制到jni文件夹之前确保它发生了这个问题。
然而，有这个问题已经开始担心我们是否以及何时将gradle实验插件（目前仅支持NDK）插入实验阶段，并将成为构建NDK代码的标准。
我们尝试了一下实验性插件，除了不同的语法（为什么???），它不支持调试本机代码作为库模块的一部分（gdb文件未打包到AAR中，并且jniDebuggable标志不再存在）。
有没有人知道这个插件何时会达到稳定的API并且可以在生产版本中使用？我们希望提前计划从调用ndk-build从shellscript到仅使用gradle的NDK构建具有相同的功能奇偶校验（以及从Android Studio免费支持C ++编辑，这对于当前配置是不可能的，因此我们依赖于{{3对于JNI胶水代码）。
答案 0 :(得分：1)
我没有路线图，但是如果你遵循依赖关系，你会发现Android实验插件仍然是实验性的，因为new Gradle object model仍然是实验性的。我希望Android Studio插件在基础Gradle代码稳定之前不会稳定。
那就是说：尽管语法差异令人沮丧，但它们通常很容易应用。更重要的是，实验插件确实提供了相当不错的调试支持。它不使用gdb（它默认使用lldb）并且它不依赖于jniDebuggable标志。您正在寻找这些这一事实让我觉得您对ndk-gdb的工作原理了解很多，并且可能构建了自己的系统，依赖于这些知识。您是否尝试过按Android Studio中的“调试”按钮？如果您的C ++代码在主项目中，它应该可以正常工作。 （不幸的是，似乎在库项目中设置断点有一些问题。）