How to add native so file dependencies in Android Gradle

@author ASCE1885 's Github book Weibo CSDN
Original link

Background

A few months ago, based on Google's leveldb, I wrote a key-value database (NoSQL) called Snappydb for the Android platform.

Because it uses native C + + code, the resulting file has the so file in addition to the jars package.

There is nothing wrong with releasing our library of functions through the MAVEN repository (as long as you have a cumbersome publishing process), Maven-android-plugin can help us to include shared libraries. Maven dependency rules allow us to specify the type of ABI (different CPU architectures) you want to get and the format of the library (our. so format).

For example, get the ARM platform shared library for Snappydb:

<dependency>  <groupId>Com.snappydb</groupId>  <artifactid>Snappydb-native</artifactid>  <version>0.2.0</version>  <classifier>Armeabi</classifier>  <type>So</type></Dependency>

If you're using Maven+eclipse ADT to build your Android app, there's no problem with this approach, but if you move the project to Android Studio+gradle, the problem comes.

Android Studio & Gradle

Android's Gradle plugin can handle all the jars dependencies (and others) that use the MAVEN repository well.

For example, declare dependencies in the Build.gradle file:

{     classpath ‘commons-io:commons-io:2.4‘}

But when it comes to the need to rely on the native library, we can no longer load it in this way, like maven:

{       classpath ‘com.snappydb:snappydb-native:2.+:arm-v7a‘}

This is because the Android Studio plugin does not have the support for the NDK.

Jnilibs saved us.

In Android Studio's 0.7.2 version of the Android plugin, Google introduced a new directory ' Jnilibs ' in the project's source sets. This means that we can copy the pre-compiled. So files into this directory, and then the Android plugin will help us package these native libraries into the APK.

.├── AndroidManifest.xml└── jniLibs    ├── armeabi    │   └── libsnappydb-native.so    ├── armeabi-v7a    │   └── libsnappydb-native.so    ├── mips    │   └── libsnappydb-native.so    └── x86        └── libsnappydb-native.so

This is a powerful feature, but developers still need to download the precompiled. So file and copy it manually into this directory, which is not perfect when we use a continuous integration system like Jenkins or Travis.

There have been many hacks techniques and workarounds to try to solve this problem, but many are actually cumbersome and require users to manually download and copy these native library dependencies.

Therefore, we need to have a better solution.

Introduction of Android-native-dependencies

Android-native-dependencies I wrote. An automatic processing find & download & copy Native library relies on the Android plugin to the Jnilibs directory, so that these libraries are automatically included in the APK build process.

This plugin uses the same repository as the declaration lookup jar package, here is an example:

buildscript {  repositories {    mavenCentral()  }  dependencies {    ‘com.android.tools.build:gradle:0.10.+‘    ‘com.nabilhachicha:android-native-dependencies:0.1‘  ‘android‘‘android-native-dependencies‘native_dependencies {    ‘com.snappydb:snappydb-native:0.2+:armeabi‘    ‘com.snappydb:snappydb-native:0.2+:x86‘}dependencies {    ...}

Protocol

DSL artifact follows the naming conventions of maven artifacts. Therefore, we can use the following two types of syntax:

• Group:name:version[:classifier] Abbreviation

//adding x86 classifier will resolve only intel‘s (.so) libnative_dependencies {    ‘com.snappydb:snappydb-native:0.2+:x86‘}//omit the classifier will resolve all supported architecturesnative_dependencies {    ‘com.snappydb:snappydb-native:0.2+‘}

• Mapping style

//adding x86 classifier will resolve only intel‘s (.so) libnative_dependencies {    group‘com.snappydb‘‘snappydb-native‘‘0.2+‘‘x86‘}//omit the classifier will resolve all supported architecturesnative_dependencies {    group‘com.snappydb‘‘snappydb-native‘‘0.2+‘}

In each syntax, classifier is optional. This means that when classifier is ignored, the plug-in will attempt to get artifacts for all types of CPU architectures (Armeabi, armeabi-v7a, x86, and MIPS).

Summarize

Before the Android Gradle plugin fully supports the NDK, using android-native-dependencies can help us build CI and automate the repetitive tasks of native dependencies.

I also recommend another great Gradle plugin written by Jake Wharton: Android-sdk-manager, which helps you to download and manage the Android SDK.

Appreciation of photography at the end of Wen

How to add native so file dependencies in Android Gradle