原文地址：　http://ph0b.com/new-android-studio-ndk-support/

During Google I/O 2015,?end of May, Google announced a new support for the NDK by Android Studio 1.3, integrating Jetbrains CLion capabilities, and the Android gradle plugin. This support has been released only in July, and while it’s really promising, it’s still in heavy development.

The new NDK support requires the use of Android Studio 1.3 RC1+/2.0+ and the android gradle-experimental plugin.?This article is for those who are willing?to give it a try.?If you’re looking into the NDK support while using the gradle(-stable) plugin, you can check this?older (but still up-to-date) article on the NDK and Android Studio.

article last updated on?2016/01/26?(gradle-experimental 0.6.0-alpha7 – Android Studio 2.0 preview 7, support for native dependencies!)

Migrating to the gradle-experimental plugin and the new com.android.model.*

The gradle-experimental 0.6.0-alpha7 requires using gradle-2.10. Start by setting?it from your project settings:

Or?inside?gradle/wrapper/gradle-wrapper.properties:

gradle-wrapper.properties distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip

1	distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip

Then,?change the reference to the android gradle plugin to the new gradle-experimental plugin, from ./build.gradle:

// Top-level build file where you can add configuration options common to all sub-projects/modules.buildscript {repositories {jcenter()}dependencies {classpath 'com.android.tools.build:gradle-experimental:0.6.0-alpha7'} }

1 2 3 4 5 6 7 8 9 10

// Top-level build file where you can add configuration options common to all sub-projects/modules. buildscript { ????repositories { ????????jcenter() ????} ????dependencies { ????????classpath 'com.android.tools.build:gradle-experimental:0.6.0-alpha7' ????} }

The gradle-experimental plugin introduces a change in the DSL. The android plugins com.android.model.application?and?com.android.model.library are replacing the former?com.android.application and?com.android.library plugins.

You need to migrate your apps and libs build.gradle files to use these new plugins. Here is an example of the same configuration, with the old DSL (top) and the new (bottom):

old DSL Java apply plugin: 'com.android.application'android {compileSdkVersion rootProject.ext.compileSdkVersionbuildToolsVersion rootProject.ext.buildToolsVersiondefaultConfig {applicationId "com.ph0b.example"minSdkVersion 15targetSdkVersion 23versionCode 4versionName "1.0.1"ndk {moduleName "mymodule"ldLibs "log"stl "gnustl_static"cFlags "-std=c++11 -fexceptions"}}signingConfigs {release {storeFile file(STORE_FILE)storePassword STORE_PASSWORDkeyAlias KEY_ALIASkeyPassword KEY_PASSWORD}}buildTypes {release {minifyEnabled trueshrinkResources trueproguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.txt'signingConfig signingConfigs.release}debug {jniDebuggable true}} }dependencies {compile 'com.android.support:support-v4:23.1.1'compile fileTree(dir: 'libs', include: ['*.jar']) }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

apply plugin: 'com.android.application' android { ????compileSdkVersion rootProject.ext.compileSdkVersion ????buildToolsVersion rootProject.ext.buildToolsVersion ????defaultConfig { ????????applicationId "com.ph0b.example" ????????minSdkVersion 15 ????????targetSdkVersion 23 ????????versionCode 4 ????????versionName "1.0.1" ????????ndk { ????????????moduleName "mymodule" ????????????ldLibs "log" ????????????stl "gnustl_static" ????????????cFlags "-std=c++11 -fexceptions" ????????} ????} ????signingConfigs { ????????release { ????????????storeFile file(STORE_FILE) ????????????storePassword STORE_PASSWORD ????????????keyAlias KEY_ALIAS ????????????keyPassword KEY_PASSWORD ????????} ????} ????buildTypes { ????????release { ????????????minifyEnabled true ????????????shrinkResources true ????????????proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.txt' ????????????signingConfig signingConfigs.release ????????} ????????debug { ????????????jniDebuggable true ????????} ????} } dependencies { ????compile 'com.android.support:support-v4:23.1.1' ????compile fileTree(dir: 'libs', include: ['*.jar']) }

new DSL Java apply plugin: 'com.android.model.application'model {android {compileSdkVersion = rootProject.ext.compileSdkVersionbuildToolsVersion = rootProject.ext.buildToolsVersiondefaultConfig.with {applicationId = "com.ph0b.example"minSdkVersion.apiLevel = 15targetSdkVersion.apiLevel = 23versionCode = 4versionName = "1.0.1"}}android.ndk {moduleName = "mymodule"ldLibs.addAll(['log'])cppFlags.add("-std=c++11")cppFlags.add("-fexceptions")stl = 'gnustl_shared'}android.signingConfigs {create("release") {keyAlias = KEY_ALIASkeyPassword = STORE_PASSWORDstoreFile = file(STORE_FILE)storePassword = KEY_PASSWORD}}android.buildTypes {release {shrinkResources = trueuseProguard = trueproguardFiles.add(file('proguard-rules.txt'))signingConfig = signingConfigs.release}} }dependencies {compile 'com.android.support:support-v4:23.1.1'compile fileTree(dir: 'libs', include: ['*.jar']) }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

apply plugin: 'com.android.model.application' model { ????android { ????????compileSdkVersion = rootProject.ext.compileSdkVersion ????????buildToolsVersion = rootProject.ext.buildToolsVersion ???? ????????defaultConfig.with { ????????????applicationId = "com.ph0b.example" ????????????minSdkVersion.apiLevel = 15 ????????????targetSdkVersion.apiLevel = 23 ????????????versionCode = 4 ????????????versionName = "1.0.1" ????????} ????} ????android.ndk { ????????moduleName = "mymodule" ????????ldLibs.addAll(['log']) ????????cppFlags.add("-std=c++11") ????????cppFlags.add("-fexceptions") ????????stl = 'gnustl_shared' ????} ????android.signingConfigs { ????????create("release") { ????????????keyAlias = KEY_ALIAS ????????????keyPassword = STORE_PASSWORD ????????????storeFile = file(STORE_FILE) ????????????storePassword = KEY_PASSWORD ????????} ????} ????android.buildTypes { ????????release { ????????????shrinkResources = true ????????????useProguard = true ????????????proguardFiles.add(file('proguard-rules.txt')) ????????????signingConfig = signingConfigs.release ????????} ????} } dependencies { ????compile 'com.android.support:support-v4:23.1.1' ????compile fileTree(dir: 'libs', include: ['*.jar']) }

To summarize the changes required: all the android declarations are now going under?model {}, the?various assignments now have to use explicitly ‘=‘, collections?must not?be overwritten,?use .removeAll(), .add(), .addAll() instead. Variants and other new configurations have?to be declared using ‘create()‘. Properties like xxxSdkVersion have?changed to xxxSdkVersion.apiLevel.

As it’s experimental, you can expect regular changes around the DSL across versions. For example, minifyEnabled has been changed to isMinifyEnabled,?then to minifyEnabled again, and now there is also?useProguard;?jniDebuggable has been changed to isJniDebuggable and then to ndk.debuggable (and is now set by default for debug builds).

You’ll notice that with both DSLs, there is a configuration block for the NDK. This is the place where you’re supposed to set all the NDK configuration when using gradle, as by default Android.mk and Application.mk files will be simply ignored.

Enjoying the new C++/NDK support in Android Studio

To activate the C++/NDK support inside Android Studio, you only need to have?a NDK module declared inside your application or library build.gradle:

Java model {//...android.ndk {moduleName = "mymodule"} }

1 2 3 4 5 6

model { ?? //... ?? android.ndk { ????????moduleName = "mymodule" ?? } }

Once it’s done, you can go to your Java sources, create a method prefixed with the native keyword, and press ALT+Enter to generate its C or C++ implementation:

Yes, it’s that magical

The implementation will be added under ‘jni‘, inside an existing cpp file if there is one, or inside a new one.

In order to get started with NDK modules, you can have a look at all the samples that have been ported to use the new gradle-experimental plugin:?https://github.com/googlesamples/android-ndk

Here is everything you can configure for a ndk module:

Java android.ndk {moduleName = "mymodule"ldLibs.addAll(['log'])ldFlags.add("")toolchain = "clang"toolchainVersion = "3.9"abiFilters.add("x86")CFlags.add("")cppFlags.add("")debuggable = falserenderscriptNdkMode = falsestl = "system"platformVersion = 15}

1 2 3 4 5 6 7 8 9 10 11 12 13 14

????android.ndk { ????????moduleName = "mymodule" ????????ldLibs.addAll(['log']) ????????ldFlags.add("") ????????toolchain = "clang" ????????toolchainVersion = "3.9" ????????abiFilters.add("x86") ????????CFlags.add("") ????????cppFlags.add("") ????????debuggable = false ????????renderscriptNdkMode = false ????????stl = "system" ????????platformVersion = 15 ????}

Debugging a NDK project

In order to get?the debug capabilities of AS, create and use a new Run/Debug configuration from the “Android Native” default. While it was possible to use GDB in Android Studio 1.3, now only the LLDB backend is available.

Use it with?your debug variant, which will have ndk.debuggable flag set to true by default.

Going further with the?NDK with Android Studio

Many advanced features, such as the ability to have dependencies between native libraries, reuse prebuilts,?tune specific toolchain options and having dynamic version codes while still having a project in a good shape is a bit complex, as the gradle-experimental plugin is still undergoing a lot of improvements across versions.

Getting the APP_PLATFORM right

When you’re building a NDK module, the android platform you’re compiling it against?is a quite?important setting, as it basically determines the minimum platform your module will be guaranteed to run on.

With earlier versions than gradle-experimental:0.3.0-alpha4, the chosen platform was the one set as compileSdkVersion. Fortunately with subsequent releases, you can now set android.ndk.platformVersion independently, and you should make it the same as your minSdkVersion.

Using?external?libraries and separate modules

with sources

If you have access to your 3rd party libraries source code, you can embed it?into your project and make it?statically compile?with your code.

There?is an example of this with the native_app_glue library from the NDK, inside the native-activity sample. For example, you can?copy the library sources inside a subfolder inside your?jni folder and add a reference to its directory so the includes are properly resolved:

android.ndk {//...cppFlags += "-I${file("src/main/jni/native_app_glue")}".toString()}

1 2 3 4

????android.ndk { ????????//... ????????cppFlags += "-I${file("src/main/jni/native_app_glue")}".toString() ????}

with sources in different modules

Now with 0.6.0-alpha7 version, you can finally have clean dependencies between native libraries, by setting the dependency on another module from your model:

build.gradle Java android.sources {main {jni {dependencies {project ":yourlib" buildType "release" productFlavor "flavor1" linkage "shared"}}}}

1 2 3 4 5 6 7 8 9

????android.sources { ????????main { ????????????jni { ????????????????dependencies { ????????????????????project ":yourlib" buildType "release" productFlavor "flavor1" linkage "shared" ????????????????} ????????????} ????????} ????}

In order to keep debugging working, you may have to edit your app-native run configuration, to add?/build/intermediates/binaries/release/obj/[abi]?to the?symbol directories.

with native prebuilts

This technique works with static and shared prebuilts too! Inside your model, you’ll have to add a?“l(fā)ib repository”:

build.gradle Java repositories {libs(PrebuiltLibraries) {yourlib {headers.srcDir "src/main/jni/prebuilts/include"binaries.withType(SharedLibraryBinary) {sharedLibraryFile = file("src/main/jni/prebuilts/${targetPlatform.getName()}/libyourlib.so")}}}}

1 2 3 4 5 6 7 8 9 10

????repositories { ????????libs(PrebuiltLibraries) { ????????????yourlib { ????????????????headers.srcDir "src/main/jni/prebuilts/include" ????????????????binaries.withType(SharedLibraryBinary) { ????????????????????sharedLibraryFile = file("src/main/jni/prebuilts/${targetPlatform.getName()}/libyourlib.so") ????????????????} ????????????} ????????} ????}

And declare the?dependency on this library:

build.gradle Java android.sources {main {jni {dependencies {library "yourlib" linkage "shared" }}}}

1 2 3 4 5 6 7 8 9

????android.sources { ????????main { ????????????jni { ????????????????dependencies { ????????????????????library "yourlib" linkage "shared" ????????????????} ????????????} ????????} ????}

Shared linkage is the default, but?of course you can use static prebuilts by using a static linkage, and declaring StaticLibraryBinary/staticLibraryFile variables.

Multiple APKs

When you publish multiple APKs (per architecture, per density, etc), you have to give them different version?Version Codes. I couldn’t find a way to do it with the current DSL, neither when using splits or abiFilters and flavors. If you do see a way, plese contact me and I’ll add it there. For now, I would advise to go back using the stable gradle plugin.

The good news is you can mix use of the stable gradle plugin, and the new experimental one, even while keeping debug features working! Please follow this gist.

Using Android.mk/Application.mk

If the built-in gradle support isn’t suitable?to your needs, you can get rid of it, while keeping the goodness of Android Studio C++ editing.

Declare a module that correctly represents your configuration, as this will help AS to correctly resolve all the symbols you’re using and keep the editing?capabilities:

android.ndk { // keeping it to make AS correctly support C++ code editingmoduleName = "mymodule"ldLibs.add('log')cppFlags.add( "-std=c++11")cppFlags.add("-fexceptions")cppFlags.add("-I${file("src/main/jni/prebuilts/include")}".toString())stl = 'gnustl_shared'}

1 2 3 4 5 6 7 8

android.ndk { // keeping it to make AS correctly support C++ code editing ????????moduleName = "mymodule" ????????ldLibs.add('log') ????????cppFlags.add( "-std=c++11") ????????cppFlags.add("-fexceptions") ????????cppFlags.add("-I${file("src/main/jni/prebuilts/include")}".toString()) ????????stl = 'gnustl_shared' ????}

Then, set the jni sources location to a non-existing folder, and the jniLibs location to libs, the default directory in which ndk-build will put the generated libs:

android.sources{main.jni {source {srcDirs.removeAll()srcDirs.add('src/main/none')}}main.jniLibs {source {srcDirs.add('src/main/libs')}}}

1 2 3 4 5 6 7 8 9 10 11 12 13

????android.sources{ ????????main.jni { ????????????source { ????????????????srcDirs.removeAll() ????????????????srcDirs.add('src/main/none') ????????????} ????????} ????????main.jniLibs { ????????????source { ????????????????srcDirs.add('src/main/libs') ????????????} ????????} ????}

This way, you can call ndk-build(.cmd) yourself from the root of your src/main directory, that will use your usual Android.mk/Application.mk files under the jni folder. Your libs will be generated inside libs/<ABI>?as usual and get included inside your APK.

You can also add?this call to ndk-build inside your gradle configuration:

build.gradle Java import org.apache.tools.ant.taskdefs.condition.Os//...// call regular ndk-build(.cmd) script from app directory task ndkBuild(type: Exec) {if (Os.isFamily(Os.FAMILY_WINDOWS)) {commandLine 'ndk-build.cmd', '-C', file('src/main').absolutePath} else {commandLine 'ndk-build', '-C', file('src/main').absolutePath} }tasks.withType(JavaCompile) {compileTask -> compileTask.dependsOn ndkBuild }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

import org.apache.tools.ant.taskdefs.condition.Os //... // call regular ndk-build(.cmd) script from app directory task ndkBuild(type: Exec) { ????if (Os.isFamily(Os.FAMILY_WINDOWS)) { ????????commandLine 'ndk-build.cmd', '-C', file('src/main').absolutePath ????} else { ????????commandLine 'ndk-build', '-C', file('src/main').absolutePath ????} } tasks.withType(JavaCompile) { ????compileTask -> compileTask.dependsOn ndkBuild }

Additional Resources

• official samples
• gradle-experimental user guide

Published by

Xavier Hallade

Software Engineer working at Intel Software and Service Group (SSG) in Paris, France. Google Developer Expert for Android.Helping developers to make a better use of Intel-based platforms, with a focus on the Android NDK. View all posts by Xavier Hallade

Posted on August 17, 2015 Author Xavier Hallade Categories Android Tags Android, Android Build System, Android Studio, gradle, NDK

37 thoughts on “The new NDK support in Android Studio”

Nelson Glauber says: August 25, 2015 at 7:37 pm

Perfect tutorial! Thanks Xavier!
Any idea when this plugin becomes will be officially released?

Reply

Xavier Hallade says: August 26, 2015 at 9:52 am

Thanks Nelson!
Everything is already released and advertised as “the official way”, even if the gradle-experimental plugin is.. experimental.
I don’t know when the experimental plugin and the new DSL will replace the current stable ones.
I’d expect this to happen around the Marshmallow release timeframe.

Reply

John Anderson says: September 2, 2015 at 12:59 am

Thanks for the tutorial! I tried following the “Using Android.mk/Application.mk” and was hoping to see my C++ source files in Android Studio but when I set my jni.srcDirs to a non-existent folder the sources are removed from my project. Do you know if there is there a way to keep the sources in Android Studio for editing/debugging but have the build done by ndk-build?

Reply

Alex Cohn says: September 3, 2015 at 11:01 pm

To fall back to Android.mk/Application.mk, I prefer to provide the actual jni directory (or directories), but disable the build step:

tasks.all {
task -> if (task.name.contains('compileDebugNdk') || task.name.contains('compileReleaseNdk')) task.enabled = false
}

Reply

Steve Madsen says: September 6, 2015 at 5:34 pm

I wanted to try to use Android.mk/Application.mk as outlined above, so downloaded the new samples from:
https://github.com/googlesamples/android-ndk
and modified the Teapot sample as follows:
* Copied Android.mk and Application.mk from the legacy sample project
* Added task ndkBuild(type: Exec) as described on your legacy ndk page
* Defined NDK_APP_OUT and NDK_APP_LIBS_OUT in Application.mk (because new lib location is e.g.
app/build/intermediates/binaries/debug/arm7/lib/armeabi-v7a)

Anyway, by setting those values the .apk is built automatically (ndk-build is called as usual, no manual command line required) and runs OK, but C++ debugging doesn’t work; by restoring android.sources.main.jni.source.srcDirs so it points to the actual jni folder (and commenting out the ndk-build task) C++ debugging works properly in Android Studio.

Any ideas what I’m doing wrong? Thank you

Reply

Francesco says: September 8, 2015 at 3:04 pm

Hey Xavier.
Nice tutorial. Thanks for that!
We are currently struggling around with getting a referenced JNI Android library module inside the same Android Studio project debuggable in another Android application module. We currently are using “compile project()” to reference the JNI lib. You are already mentioning that debugging external libraries are not supported yet. You solution would be to copy the source code into some folder of the actual Android module. We really don’t want to copy the files to achieve that. Isn’t there any other solution that come to your mind?

Reply

Steve Madsen says: September 14, 2015 at 10:10 pm

I tried your updated instructions for using Android.mk/Application.mk with experimental gradle (goal is C++ debugging in Android Studio to retire Eclipse). But, getting this error:

Error: duplicate files during packaging of APK /app/build/outputs/apk/app-arm7-debug-unaligned.apkPath in archive: lib/armeabi-v7a/gdb.setupOrigin 1: /app/build/intermediates/binaries/debug/arm7/lib/armeabi-v7a/gdb.setupOrigin 2: /app/src/main/libs/armeabi-v7a/gdb.setup You can ignore those files in your build.gradle:android {packagingOptions {exclude 'lib/armeabi-v7a/gdb.setup'}}

1 2 3 4 5 6 7 8 9 10

Error: duplicate files during packaging of APK /app/build/outputs/apk/app-arm7-debug-unaligned.apk Path in archive: lib/armeabi-v7a/gdb.setup Origin 1: /app/build/intermediates/binaries/debug/arm7/lib/armeabi-v7a/gdb.setup Origin 2: /app/src/main/libs/armeabi-v7a/gdb.setup You can ignore those files in your build.gradle: android { ??packagingOptions { ????exclude 'lib/armeabi-v7a/gdb.setup' ??} }

Would prefer to not have to use workarounds if possible, do you have any ideas? (Thank you again for maintaining these pages, they are very useful resource)

Reply

Steve Madsen says: September 14, 2015 at 10:22 pm

P.S.
Tried adding this to app/build.gradle but to no avail:

android.packagingOptions {excludes += ['src/main/libs/armeabi-v7a/gdb.setup']}

1 2 3

????android.packagingOptions { ????????excludes += ['src/main/libs/armeabi-v7a/gdb.setup'] ????}

Reply

Steve Madsen says: September 14, 2015 at 11:34 pm

P.S.2
By changing jniLibs I avoid the duplicate error above, and the app builds and runs — but no C++ debugging in android studio (breakpoints ignored, though the pause/start buttons in the Debugger window work)

And of course, the build variant shouldn’t be hardcoded like this (debug, arm should be replaced by variables)

jniLibs {source {//srcDirs = ['src/main/libs']srcDirs = ['build/intermediates/binaries/debug/arm7/lib/armeabi-v7a']}}

1 2 3 4 5 6

jniLibs { ????????????????source { ????????????????????//srcDirs = ['src/main/libs'] ????????????????????srcDirs = ['build/intermediates/binaries/debug/arm7/lib/armeabi-v7a'] ????????????????} ????????????}

Reply

Steve Madsen says: September 20, 2015 at 11:19 pm

Having troble setting main.jniLibs.source.srcDirs as instructed above — using this:

jniLibs {source {srcDirs = ['src/main/libs']}}

1 2 3 4 5

jniLibs { ????????????????source { ????????????????????srcDirs = ['src/main/libs'] ????????????????} ????????????}

I get this error:

Execution failed for task ':app:packageArm7Debug'. > Failed to add {project_path}/app/build/intermediates/binaries/debug/arm7/lib/armeabi-v7a/gdb.setup

1 2	Execution failed for task ':app:packageArm7Debug'. > Failed to add {project_path}/app/build/intermediates/binaries/debug/arm7/lib/armeabi-v7a/gdb.setup

For some reason the gdb.setup is problematic, an attempt is usually made to install it twice resulting in some sort of “duplicate” error.

Reply

Koki says: December 16, 2015 at 6:09 pm

Hi,
This is really nice tutorial.
I wonder if there has been any findings on this issue.
I’ve been facing exactly the same message, i.e. “Failed to add /……./gdb.setup”, and I can’t find any other site mentioning this message.
My setup is gradle 2.6 with experimental-plugin 0.3.0-alpha7 targeting native debugging.

Reply

Steve Madsen says: October 7, 2015 at 7:11 am

Just a followup to a previous comment: I think some of the problems I was having may have been due to attempting to include the (incompatible?)

'NDK_DEBUG=1'

1	'NDK_DEBUG=1'

switch to ndk-build e.g.

commandLine 'ndk-build', 'NDK_DEBUG=1', '-C', file('src/main').absolutePath

1	commandLine 'ndk-build', 'NDK_DEBUG=1', '-C', file('src/main').absolutePath

(Still can’t get breakpoints to work, just start/pause control from Android Studio debugger panel)

Reply

Xavier Hallade says: October 19, 2015 at 4:38 pm

Hi Steve,
I’ve got the same troubles to get NDK debugging working with AS 1.4/1.5 and the gradle-experimental plugin while keeping Makefiles.
It was working for me before 1.4 release when using GDB backend, which doesn’t seem to be available anymore.

Reply

Ronnie Erickson says: November 19, 2015 at 8:03 pm

Any idea how to get around this? I am dealing with trying to move a really complex build that uses a lot of common code for other platforms over to Android Studio. I can build it fine with using my own Android.mk/Application.mk like I did with ADT. But I can’t build with the experimental gradle because I can’t find a way to define all of the common files that are needed that sit outside of the jni directory. Any thoughts on how I could build about 300 cpp files in multiple directories that are not inside the jniSource directory? In addition to that, our make files pull in some static libraries that we use.

I’ve been scouring the web since Google really hasn’t had great documentation…especially in terms of their definition of “NDK Support”. Your blog has been the most useful. Thanks!

Reply

Victor Mak says: January 7, 2016 at 4:56 am

Hi, Ronnie. I am encountering the same situation, any clues yet? Thanks!

Reply

Xavier Hallade says: January 19, 2016 at 6:28 pm

Here is a snippet that may help you to add all your external source directories to your build:

def extSourcesDirsPath = “…”
cppFlags += “-I${file(extSourcesDirsPath)}”.toString()
file(extSourcesDirsPath).eachDirRecurse { dir ->
cppFlags += “-I${file(dir)}”.toString()
}

Reply

Steve Madsen says: December 3, 2015 at 3:11 pm

Thank you Xavier — I noticed a couple of weeks ago the SDK added module “LLDB” in SDK Tools — hopefully this will eventually restore functionality lost when gdb support was removed from Android Studio 1.4.

Reply

Rocky says: October 9, 2015 at 7:17 am

Thanks Xavier!
I followed the step to create a native method and press ALT+Enter
but it always generate a .c file.
How can I use ALT+Enter to generate a .cpp file?

Reply

Hua says: December 15, 2015 at 6:04 am

I encountered the same problem as you.

Reply

Feisal says: October 16, 2015 at 5:30 am

I have some c++ source code with dependencies to OpenCV, would I be able to link them using gradle build?

Reply

Anthony says: October 28, 2015 at 7:14 pm

Great post, thanks for keeping up with the updates and going into more than cursory detail. Where do you get the information on each new release? I can follow the releases on the repository, but I can’t seem to find any release notes anywhere.

Reply

Pingback: Java Annotated Monthly – December 2015 | IntelliJ IDEA Blog

Krishna says: December 22, 2015 at 10:57 am

Hello Xavier, Thanks for the detailed steps.. its a cake walk.
In the tutorial you mentioned – “you can go to your Java sources, create a method prefixed with the native keyword, and press ALT+Enter to generate its C++ implementation:”
when i did the same, its generating C implementation instead of C++; I have some C++ dependencies. How to get the C++ implementation instead of C implementation.

Reply is appreciated.

Reply

Xavier Hallade says: December 22, 2015 at 11:01 am

You’re right, it’s generating a C implementation when you don’t have sources yet, not a C++ one.
I don’t know a way to automatize this, but you can simply rename the file to cpp, and change the (jniEnv*)->XXX(env, …) calls to jniEnv->XXX(…) to make it C++.

Reply

Olivier Roblin says: January 19, 2016 at 2:07 pm

Hi Xavier,
Thanks a lot for the post!
I have an issue with the native debugger (it just doesn’t work, doesn’t stop at breakpoints, etc…). The issue occurs either if I build native code with gradle or with Android.mk/Application.mk like you describe.
The problem may be due to my specific overall architecture : The app module depends to a library module in which I have my native .so libs. For debugging, I run the app with the native debugger but the native code to attach the debugger is inside the library module.
In the Debug configuration, I add ‘moduleLib/src/main/obj/local/armeabi-v7a’ directory to the “Symbol directories”.
This used to work with ADT.
Do you have an idea of what is wrong ?
Have you ever tried to debug native code inside a Java Library module ?

Thanks,

Reply

Xavier Hallade says: January 19, 2016 at 6:17 pm

Hi,

I’m using a library module in one of my projects too and I got debug working well.

I had to add ./build/intermediates/binaries/*release*/obj/[abi] to the Symbol directories.

Here is a gist extracted from my project: https://gist.github.com/ph0b/0575b30b67e04f2ec10f

Reply

Olivier Roblin says: January 21, 2016 at 3:20 pm

Yes it works!
I added symbols from src/main/obj/local/[abi] in the case of Android.mk/Application.mk build. It doesn’t work.
For the gradle build case, I don’t remember which symbol directory I added but certainly not the good one. With ‘./build/intermediates/binaries/*release*/obj/[abi]’, it’s ok.
Thanks Xavier.

Reply

Jimmy says: January 26, 2016 at 5:29 am

I went through the tutorial over and over again, tried every permutation of the solutions in StackOverflow, and I’m still getting the message:

Error:Gradle version 2.9 is required. Current version is 2.10.

Do you have any idea of what could be wrong? I changed gradle-wraper.properties manually, tried to set it on the module settings, went to every single line over and over again, but still nothing.

Reply

Xavier Hallade says: January 26, 2016 at 1:57 pm

There are strong requirements regarding the various versions you’re using between gradle, gradle-experimental plugins and gradle itself.
You can use gradle-experimental:0.6.0-alpha7 and/or gradle:2.0.0-alpha7 with gradle 2.10 – I’ve updated the article accordingly.
Earlier alphas (I don’t remember which one exactly) needed gradle 2.9 – I’m trying to stick to the latest versions of everything, until anything becomes stable

Reply

Jimmy says: January 27, 2016 at 12:42 am

Hi Xavier, thanks for the help! Now I get the following error:

Error:Exception thrown while executing model rule: BaseComponentModelPlugin.Rules createBinaryTasks
java.lang.NullPointerException (no error message)

Do you have any idea of what could be wrong? I have been using eclipse for Android Development for 4 years, and I can’t believe that I have such difficulty switching to AS. I have 3 days working on this :S

Reply

Xavier Hallade says: January 27, 2016 at 11:40 am

That’s the problem with the alpha status, the error messages are still mostly cryptic.. Maybe there is a syntax error somewhere, like in this issue: https://github.com/googlesamples/android-ndk/issues/146

Reply

Olivier Roblin says: January 26, 2016 at 2:28 pm

Hi Xavier,
I have another question :
* When I build my native code with former Android.mk/Application.mk, I don’t succeed in attaching the symbols and the debugger doesn’t work. (I add myLib/src/main/obj/local/[abi], which contains the symbolicated .so, to the Symbol directories).
Do you know if it should work ? Have you ever tried this ?
* The problem is actually critical, because I would have to include pure assembly files in my build. You already answered to someone (here : http://stackoverflow.com/questions/32092144/how-to-compile-android-ndk-with-gradle-that-contain-arm-assembly-optimizaions) that it’s probably not supported by gradle build. Still not more information about this ?

Olivier

Reply

Xavier Hallade says: January 26, 2016 at 2:42 pm

You mean that you need to have breakpoints and symbols resolution working in your ndk code compiled with Android.mk/Application.mk, inside AS?
I have tried it a bit and failed, like you did. Maybe there is a way to make it work, but I haven’t found it.

For your use case, I’d generate static prebuilts using ndk-build, that are only including your assembly files and make them usable to other modules that will be compiled using gradle (see this gist for native dependencies: https://gist.github.com/ph0b/418132cb2f3f03a5534c). This way you will not have symbols and debugging from AS for all of your code, but at least you’ll have it for most of it.

Reply

Olivier Roblin says: January 26, 2016 at 5:03 pm

Yes that’s exactly what I currently do.
But I wondered if you had a solution because you say “If the built-in gradle support isn’t suitable to your needs, you can get rid of it, while keeping the goodness of Android Studio C++ editing/debugging.”
I thought you succeeded in debugging build from manual ndk-build.

Thanks anyway,
Olivier

Reply

Xavier Hallade says: January 26, 2016 at 5:12 pm

I actually did earlier, when it was possible to use the gdb backend. Now that only lldb is available I couldn’t make it work with Android.mk/Application.mk – I’ll update the article accordingly.

Reply

Olivier Roblin says: January 29, 2016 at 4:09 pm

Do you know if it’s possible to add ABI specific options in gradle ? For example, adding
cppFlags.add(“-DUSE_NEON=1”) for armv7 build
and cppFlags.add(“-DUSE_IPP”) for x86 build ?

Of course, having different flavors would do the job, but I would prefer to have my x86 and armv7 libs in a single apk.

Is it possible to test the ABI in gradle, somethink like :
if (abi == “x86”) cppFlags.add(“-DUSE_IPP”) ?

Beside, is it possible to add cppFlags for some files only ?

Or the only way to do that is having different flavors and different apk ?

Reply

Xavier Hallade says: January 29, 2016 at 4:45 pm

I don’t see a way to do this yet outside of Android.mk or flavors.
Although in your case, if it’s only to have various defines depending on the ABI, you could include a config header through cppFlags (-include xxx.h), and in that header, have your defines defined according to each ABI.

Reply

總結(jié)

以上是生活随笔為你收集整理的The new NDK support in Android Studio 1.3的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。