5

I want to do something conceptually simple but for which I cannot find any documentation. I have a certain libraries for which I compiled SO files for all the platforms I am interested.

Now I would like just to generate an AAR file containing those so files.

I know the AAR file has to have a structure like: /jni//mylib.so

What I do now know is what kind of Manifest/other metadata I should produce.

Ideally it would be great to generate that using Gradle but I just need this thing done so it makes sense also writing a simple script generating a zip and then rename it.

Federico Tomassetti
  • 2,100
  • 1
  • 19
  • 26
  • Normally Android Studio will build AAR files for you. You just make sure that the libraries are in jniSrc directory. The latest experimental plugin adds [pure native dependencies](http://tools.android.com/tech-docs/new-build-system/gradle-experimental#TOC-NDK-Dependencies) – Alex Cohn Dec 17 '15 at 20:44
  • 1
    Possible duplicate of [How do I package .so files into my .aar archive?](http://stackoverflow.com/questions/29803921/how-do-i-package-so-files-into-my-aar-archive) – skywinder Nov 23 '16 at 12:05

1 Answers1

5

Publishing an AAR containing native libraries is pretty straight-forward. Advantages I've found include:

  • If using for multiple projects, of course there's a benefit in not duplicating the native code
  • Application build is much faster, as you don't have to do the NDK compilation in the app. So if the native code changes less frequently
  • In my case, there was an incompatibility with certain NDK and SDK combinations. Being able to build the library with an older SDK and the app with a newer version is working pretty well. (avoids having my app stuck on an older SDK version due to an NDK issue)
  • can have unit tests against the library code that are completely independent of any including application. (Application unit tests can still test the library also)

Trade off is that there are a few extra steps to update the c-code, but if that changes less frequently than the app, then it's a good trade off.

It's worth noting that I get a warning: Current NDK support is deprecated. Alternative will be provided in the future. on every build. AFAIK, the alternative isn't yet available - my definition of deprecated would be that it's not deprecated until that happens.

Here are the key points of how I have it working:

  • c and cpp code lives under src/main/jni

  • app/build.gradle (a lot of this also applies to using NDK in an app project):

    • apply plugin: 'maven' at top under apply plugin: 'com.android.library'

    • Add c/cpp header containing directories under android block:

      sourceSets.main {
  jni.srcDirs 'src/main/jni/Thirdparty/lib1/headers', ... 
}

    • under android/defaultConfig (whatever options your native code may need) :

          ndk {
      moduleName "module_name"
      cFlags "-std=gnu++11 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__STDC_LIMIT_MACROS -fexceptions"
      ldLibs "log"
      stl "gnustl_static"
    }

    • Outside of the android block - to tell gradle how to publish the library to a maven repo. This just pushes to the local Android sdk repo directory, but it's also possible to pushed to shared repositories (I'm currently pushing to an internal nexus repo also - gradle code for that not included here)

      uploadArchives {
  repositories {
    mavenDeployer {
    repository(url: "file://localhost" + System.getenv("ANDROID_HOME") + "/extras/android/m2repository/")
    pom.version = '1.0-SNAPSHOT'
  }
  pom.groupId = 'com.example.groupid'
  pom.artifactId = 'library_name'
}
  • ./gradlew uploadArchives then publishes a valid aar to my local repo and I can depend on it from an application project using with compile 'com.example.groupid:library_name:1.0-SNAPSHOT' in app/build.gradle under android/dependencies block
  • under the covers, android sdk merges aar's into the application's apk as if they'd been built as part of the app project (including a number of jni/*/module_name.so files)
Stan Kurdziel
  • 5,476
  • 1
  • 43
  • 42