Geek Answers Handbook

Support for NDK in AndroidStudio and the choice between Android Studio and Eclipse

I ended up in a "race state", choosing between Android studio and Eclipse:

  • My project needs C ++ code to be associated with my application. NDK is currently not supported (deprecated ?!) in Android Studio 1.0. Saying obsolete does not reveal the entire ANGULAR IMAGE. It is currently completely unknown how easy it is to link your precompiled .so libraries to a project. Not to talk about compilation ... Although many solutions for this are published daily on stackoverflow. Most of them are associated with some pre-beta versions , and simply do not work, not out of the box, and not after they spent a lot of time minting them.

The solutions I've checked so far are:

a. NDK With Android Studio

b. Android studio, gradle and NDK

from. NDK gradle / Android Studio support, are you planning to release it?

e. Using Android NDK with Android Studio - Part 1

e. Using NDK with Android * Studio

f. Android Studio, gradle and NDK integration

All of which differ from each other and are difficult to integrate , and simply do not work ...

  1. The development for the future of Lollipop is that it is blocked by Google, as they simply will not allow their new SDK to be used for some time in Eclipse! ?? Why?

This brings me to the question. Which environment should I choose? Does Google really care about its developers? Can't they just provide some simple solution for the current version?

+1
source share
1 answer

It is currently completely unknown how easy it is to link your pre-compiled .so libraries to a project.

Not true. Previously, you zipped them up, renamed the archive to the bank, and included it in your project. Now you add specific versions of ABI to the <project>/<module>/src/main/jniLibs/<abi> (provided that you have not changed your source codes).

jniLibs directory structure

This is one of the main advantages. You can split the resulting .apk into several ABI-based ones, each of which includes only its specific native libraries. The following code example ensures that you get multiple .apk based on ABI, each of which will have a different versionCode , as required, looking like this: Axxxxxx where A is the ABI code, and you get 6 digits for the version source code, The sample code should used in the application module. Native libraries will be automatically selected from all application dependencies.

 android { //... splits { abi { enable true reset() include 'x86', 'armeabi-v7a', 'armeabi' // specify abis you want universalApk true // if you want a composite apk as well } } project.ext.versionCodes = [ // keep this as is 'armeabi':1, 'armeabi-v7a':2, 'arm64-v8a':3, 'mips':5, 'mips64':6, 'x86':8, 'x86_64':9 ] android.applicationVariants.all { variant -> // assign different version code for each output variant.outputs.each { output -> // keep this on one line - groovy doesn't need semicolons, the value might not be complete then output.versionCodeOverride = project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode } } }

The above example works well in my project.

Do not talk about compilation ...

Given that I spent several hours converting my own non-AS library project into AS and failed, I would suggest that if you had already developed your own project, save it outside AS and create it as .so with.

I will review this and update the answer when I find something useful. However, I already found one of your original sources quite interesting ( http://www.shaneenishry.com/blog/2014/08/17/ndk-with-android-studio/ ). The basic premise is that you replace Android.mk , Core.mk and Core2.mk instructions in the build.gradle file. According to http://ph0b.com/android-studio-gradle-and-ndk-integration/ (section Compiling your C/C++ source code from Android Studio ) you can override this default behavior (ad-hoc makefile from gradle instructions) .

+2
source

More articles:


All Articles