Android gradle experimental plugin roadmap

Question

At our company we are developing an Android SDK that contains both Java and native part. We pack the SDK in AAR format that contains all resources, java classes and native bits. According to AAR specification, native libraries should be placed inside jni folder inside AAR bundle. Since current gradle plugin does not support advanced NDK uses cases and since we have a very mature Android.mk file that has evolved over 3 years of development, we prepare AAR by calling custom shell script from gradle task. This shell script builds the NDK with ndk-build command and the task that runs this script is put as a dependency of javaCompile task (there are multiple flavors of our code and each flavor has its own rules for NDK which are preloaded from a definition file and then given to ndk-build as command-line arguments).

Finally, when everything gets compiled, we have a Copy task which copies the native libs into jni folder inside build/intermediates/bundles (the folder that eventually gets zipped into AAR). This worked correctly until we updated our project to use gradle plugin v1.5.0.

In v1.5.0 something called Transform API was introduced into plugin. Although we do not use this, this Transform step does some transforming of native libs in task transformNative_libsWithSyncJniLibsForFlavorNameBuildTypeName which happens somewhere after we have already copied our libs into jni folder and causes deletion of all data in jni folder. This finally results with AAR that does not contain native libs and crashes as soon as native methods are required.

We workarounded this issue by using project.tasks[taskName] to obtain that task and make sure it happens before we copy our libs into jni folder.

However, having this problem has started to worry us if and when will the gradle-experimental plugin (the only that currently supports NDK) be put out of experimental phase and will become a standard for building NDK code.

We experimented a bit with that experimental plugin and besides different syntax (why???) it does not support debugging native code as part of library module (gdb files are not packaged into AAR and jniDebuggable flag does not exist anymore).

Does anyone know when this plugin will reach a stable API and will be ready for use in production builds? We want to plan ahead our migration from calling ndk-build from shellscript to gradle-only NDK build with same feature parity (plus free support for C++ editing from Android Studio, which is not possible with current configuration, so we rely on different editor for JNI glue code).

Answer 1

I don't have a roadmap, but if you follow the dependencies, you'll see that the Android experimental plugin is still experimental because the new Gradle object model is still experimental. I'd expect that the Android Studio plugin won't be stable until the underlying Gradle code is stable.

That said: although the syntax differences are frustrating, they are usually fairly easy to apply. More importantly, the experimental plugin does offer fairly good debugging support. It does not use gdb (it uses lldb by default) and it doesn't rely on the jniDebuggable flag. The fact that you're looking for these makes me think that you know a lot about how ndk-gdb works, and have perhaps built your own system that relies on that knowledge. Have you tried simply pressing the "Debug" button in Android Studio? It should work fine if your C++ code is in your main project. (It seems to have some issues setting breakpoints in library projects, unfortunately.)