1

I got to a 'race condition' choosing between Android studio and Eclipse:

  1. My project needs some C++ code to be linked with my app. Currently NDK is not supported (deprecated ?!) in Android Studio 1.0. Saying deprecated does not reveal the whole UGLY PICTURE. Currently it's quite unknown how to even just link your pre-compiled .so libraries to a project. Not to talk about compiling... Although many many solutions to this are being posted in stackoverflow every day. Most of are related to some pre-beta versions, and just dont work, not out of the box, and not after wasting some considerable time cheking them.

Solutions I have checked so far:

a. NDK With Android Studio

b. Android studio, gradle and NDK

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

d. Using the Android NDK with Android Studio- Part 1

e. Using the NDK with Android* Studio

f. Android Studio, gradle and NDK integration

All of which are quite different and complex to integrate, and just wont work...

  1. Developing for future Lollipop is, well, being blocked by Google, as they will just not allow using their new SDK's for some time now in Eclipse !?? Why?

Which brings me to the question. In which environemnt should I choose? Do google really care about their developers that much? Can't they just provide some simple usage solution for current version??

Community
  • 1
  • 1
rubmz
  • 1,947
  • 5
  • 27
  • 49
  • What have you found so far? You haven't listed any sources when you said "Although many many solutions to this are being posted in stackoverflow every day" either. – Sufian Mar 09 '15 at 11:30
  • I will check and update – rubmz Mar 09 '15 at 11:30
  • 1
    **1a)** You can link precompiled .so libs by putting them in `/src/main/jniLibs/`. They will even be auto included from library modules to your app modules. Even splitting .apk to decrease size works. **1b)** As for compiling NDK in AS I have no idea, never done that. – Eugen Pechanec Mar 09 '15 at 11:44
  • Indeed, people seem to forget that it was years between the introduction of the NDK as a command-line toolset and the later "not necessarily worth bothering with" integration with Eclipse. Before the later was introduced, or for those who chose to pass on it, building the NDK code separately and having Eclipse or whatever Android build setup was used pick up the results was (and still is) perfectly workable, and if the AS can do similarly as Eugen's comment indicates, then there really isn't a "problem" but merely a lack of a "convenience". – Chris Stratton Mar 09 '15 at 12:13
  • @EugenPechanec With the abundance of solution for the problem, considering people usually try to get the complete solution (compiling too) in too, this is completely not as obvious. Add to it the mess AS brings when porting in from Eclipse - it brings in compilation gradle rules which just don't work. Put in the mess of understanding AS after getting used to Eclipse... I hope you get the idea. Anyway, I will check your solution, and you could just put it as "Answer", this would help other confused AS newbies – rubmz Mar 09 '15 at 12:16
  • @ChrisStratton this is really not the case, nor the question... It should be explained plainly by google how to integrate NDK into imported applications. Current situation is a complete mess. – rubmz Mar 09 '15 at 12:17
  • @rubmz considering that you can still use Eclipse, there's no need to sulk over the problem. The only reason an Android dev can be annoyed on Google is why did it took so long to boot Eclipse. – Sufian Mar 09 '15 at 12:33
  • @Sufian you don't have newer API's beyond 21 in Eclipse.. Build tools too arent up to date. And it's a general mess to make a real choise this way.. – rubmz Mar 09 '15 at 13:27
  • 21 is the latest and I'm using AS. Build tools are same on both. Please check your SDK setup. – Sufian Mar 09 '15 at 13:54

1 Answers1

2

Currently it's quite unknown how to even just link your pre-compiled .so libraries to a project.

Not true. In the past you would zip them, rename the archive to jar and include it in your project. Now you add ABI specific versions to <project>/<module>/src/main/jniLibs/<abi> directory (provided you didn't alter your sourcesets).

jniLibs directory structure

This has one major advantage. You can split the resulting .apk into several based on ABI each including only its specific native libraries. The following code sample will ensure you get multiple .apks based on ABI, each will have a different versionCode as required looking like this: Axxxxxx where A is ABI code and you get 6 digits for your original version code. The sample code is supposed to be used in an application module. Native libraries will be picked from all app's dependencies automatically.

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 is working well within my project.

Not to talk about compiling...

Considering I spent some hours trying to convert a non-AS native library project to an AS one and failed, I'd suggest that if you have already developed native project, keep it outside of AS and build it as .sos.

I will look into this and update the answer once 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 with 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).

Eugen Pechanec
  • 37,669
  • 7
  • 103
  • 124
  • Thumbs up Eugen! Great answer. Really. I just might try it. But be honest, do you think the work you made took less than a week? Did you just read it in the manuals, or did you investigate deep into the internet just to know.. how to link a library to the project??? Just link.. Why should I do so much work for just.. linking? WTF?! This is GOOGLE? Google should provide simple method for this. At least for developing one single APK, not multiple, and let me just drop the .so files somewhere. This Gradle Infinite Wisedom they try to force us into don't help either. It reminds Symbian too much!!! – rubmz Mar 09 '15 at 20:15
  • 1
    We know that the Android C/C++/GPU Developer Tools aren't anywhere close to where they need to be and we're working very hard to fix that. – vharron Mar 09 '15 at 21:02
  • Honestly I just got lucky I needed this feature after it was implemented and ready for me. [This article](http://ph0b.com/android-studio-gradle-and-ndk-integration/) helped me so much because it lists how linking `.so` in AS developed over time. – Eugen Pechanec Mar 10 '15 at 00:09