New way to hack ndk so libs copy when using gradle plugin 0.4.0+

[Yonnie Lu]

There is a topic we known as: "https://gist.github.com/khernyo/4226923", But i have try this method in gradle plugin 0.4.0+, it doesn't copy the so libs to apk.

So I'm confused. But I figured out a new way to hack this before gradle support.

The way is: use jar to copy so libs. Is it amazing?right?. Let me show how-to:

If you have the following structure:

project

|---libs

      |---armeabi/xxx.so

      |---xxx.jar

      |---xxx.jar

1.We archive the armeabi folder to zip named:armeabi.zip with the folder in zip like: lib/armeabi/xxx.so

2.Rename armeabi.zip to armeabi.jar and put armeabi.jar into libs folder with the other jars.

3.And when we call 

dependencies {

compile fileTree(dir: 'libs', include: '*.jar')

}

in our build.gradle file, it will extract the so libs to the apks.

As we know, only class files will be packed into classes.dex file and other files will be extracted to the apk as the structure in the jars.

So, That's how-to hack. Easy and amazing. Cool,right?

[Xavier Ducrohet]

yeah that should work.

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Traun Leyden]

I just tried this, and it worked great!  My build.gradle file is much cleaner now.

[Jeff Campbell]

The only problem with this still, is that you have to commit your .so files into each projects' source control (such as git/svn) instead of adding a simple shared repository dependency to the build.gradle file. Example:

dependencies {

    compile 'net.sqlcipher:libdatabase_sqlcipher:2.1.1:so:armeabi'

[Levente Kovacs]

I'll answer myself, maybe will also be useful for other "blind" people: the error I made was in using "libs"... when I noticed it and changed it to "lib" (and using the original idea of creating the jar with the lib/armeabi/ structure) everything worked. I'm happy with this solution, since I really didn't want to go back to using eclipse.

So thanks again for the original poster!

On Tue, Jun 11, 2013 at 9:11 AM, Levente Kovacs <leve...@gmail.com> wrote:

Hi,

I've also tried the above suggestion, first by creating a .jar with the .so files, then by creating a .jar file with the libs/armeabi/*.so structure, in both cases I keep getting unsatisfied link errors.

Any suggestions?

Thanks!


On Sunday, June 9, 2013 9:07:39 PM UTC+2, Przemek Jakubczyk wrote:

Wow the idea looks very promising. I have two small question:

1. the armeabi.jar just contains .so files? I'm trying to integrate sqlcipher so:

libdatabase_sqlcipher.so

libsqlcipher_android.so

libstlport_shared.so

no subfolders, right?

2. for x86 support you would make the same trick but using x86 .so files and put them to x86.jar?

Thanks for help

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.

[Przemek Jakubczyk]

@Levente Kovacs 

you're right, it has to be "lib" not "libs". Otherwise it won't work!

so the jar has structure:

|---lib/

    |---armeabi/

       |---libdatabase_sqlcipher.so

       |---libsqlcipher_android.so

       |---libstlport_shared.so

    |---x86/

       |---libdatabase_sqlcipher.so

       |---libsqlcipher_android.so

       |---libstlport_shared.so

I've named it sqlcipher_so_files.jar

and put into "libs" folder

|---libs

    |---sqlcipher_so_files.jar

    |---sqlcipher.jar

    |---xxx.jar

and build.gradle

buildscript {

    repositories {

        maven { url 'http://repo1.maven.org/maven2' }

    }

    dependencies {

        classpath 'com.android.tools.build:gradle:0.4.2'

    }

}

repositories {

    mavenCentral()

}

apply plugin: 'android'

dependencies {

    compile fileTree(dir: 'libs', include: '*.jar')

    compile 'com.google.guava:guava:r09'

}

android {

    compileSdkVersion 17

    buildToolsVersion "17.0.0"

    defaultConfig {

        minSdkVersion 14

        targetSdkVersion 16

    }

}

@Yonnie Thanks for investigating this trick 

[Nicholas Nezis]

@Przemek Jakubczyk

Thanks for showing your structure. I totally missed the need to use the lib folder in the jar. I was able to combine my 3 jars into one with the 3 subfolders for each architecture and it worked great. Totally fixed the issues I was having. In my case I was doing this with AndEngine and the Box2D AndEngine library. Thanks again!

[Jeff Lott]

Thank you Yonnie Lu!

I was banging away at this for a quite a while.  If you're ever in Blakeslee PA, USA I'll buy you a beer.

[Yonnie Lu]

Yeah, should use lib/armeabi/xx.so in the jar contains so, not libs, i show libs because i put jars in libs dir. Read carefully of my post.

[Matthias Kutscheid]

Hi! I'm trying to copy some libraries into my project like this and get out of memory errors and if the build succeeds gradle tells me that there are duplicate files. The libraries I'm about to copy are about 8 megabytes big (all architectures together) and the process consumes about 500 MB or RAM.

If the build succeeds (which happens sometimes, but is not reproducible) I get a proper APK and everything works fine, so the paths are OK.

Does anybody have any idea about the memory issue and duplicate file message?

[Arvid Gerstmann]

Seems like it doesn't work with 0.5.0 anymore ...

[Michael Janin]

Just did a rebuild to test, and it works fine (with 0.5.+, though it should not make any difference).

[Roman Romkin]

has anyone created a task to package the *.so files into jars so it is automatic ? i was also trying to figure out if it is simply possible to copy files into bundles folder before bundle step (since we needed for the library and Not apk) but my gradle knoweldge is very limited i couldn't figure out how to determine which buildtype it is (debug or release) to construct a path.

Thanks.

[Roman Romkin]

Looks like i have managed to create a script which can do it automatically

task nativeLibsToJar(

    type: Zip,

    description: 'create a jar archive of the native libs') {

    destinationDir file("$buildDir/native-libs")

    baseName 'native-libs'

    extension 'jar'

    from fileTree(dir: 'libs', include: '**/*.so')

    into 'lib/'

}

tasks.withType(Compile) {

    compileTask -> compileTask.dependsOn(nativeLibsToJar)

[Nimer]

Your solution indeed packs .so files into jar... but there is a slight issue with it - generated jar is put into package only after second build.

First build will create jar but will not, sadly, include that jar into the build... as it does not exist when dependencies check is evoked :(.

So my question is: do you people know a way to force those jar's created at compile time to be included in final apk at first build?

Thanks in advance!

[Michael Janin]

One way is to : 

• generate the archive into $projectDir/libs
  
• add it to the compile dependencies (ie compile files(libs/my-generated-archive.jar)
  

[Tony Cosentini]

Has anyone found a solution to the first build not having the native library jar?

[Przemek Jakubczyk]

Nope

[ori....@gmail.com]

Is there no way to either:

1. Delay/Custom a dependency resolve?

2. Depend the native library project build on another gradle project only executes: ndkBuild+nativeLibsToJar?
3. Modify/Hook the aar packaging task to include build/native-libs directory?

Is specifying a compile dependency on native-libs.jar the only way to pack it into the aar? Can someone explain if/why?

Thanks.

[ori....@gmail.com]

Alternatively, is there a way to depend the entire (naive lib project) build on running the nativeLibsToJar task? (This is basic gradle perhaps, but not obvious how to do, for me at least).

[Sergey Vasilinets]

Hi, There is a hack that fixes first build.

You should add following dependencies block:

dependencies {

    compile 'com.your.usual:deps:1.0.0'

    compile 'com.your.unusual.:deps:2.0-SNAPSHOT'

    def nativeLibs = new File("$buildDir/native-libs")

    if (!nativeLibs.exists()) {

        nativeLibs.mkdirs();

    }

    new File("$nativeLibs/native-libs.jar").createNewFile()

    compile fileTree(dir: nativeLibs)

}

[Vladimir Zvezda]

For me using the packageApplication.packagedJars property solved the problem of attaching different native libraries to the final apk depending on buildType or produce flavor:

android.applicationVariants.all { variant ->

   // ... 

   variant.javaCompile.dependsOn taskJniJar // custom taskJniJar package the specific to build type *.so files into Jar

   variant.packageApplication.packagedJars += taskJniJar.archivePath // put the jar file with *.so files into the apk.

[Shubham Goyal]

Hey.

I tried the exact same thing. But getting "java.lang.UnsatisfiedLinkError" at runtime. I am using native libs in a library project. Here is the structure of my library project - 

      |--libs

          |---native_so_files.jar

I have created a folder named native_so_files with the below structure and then converted it into a zip named native_so_files.zip followed by renaming the zip file to native_so_files.jar

|--native-so-files

     |--lib

         |--ameabi

                 |--libcom_couchbase_touchdb_TDCollateJSON.so

         |--mips

                |--libcom_couchbase_touchdb_TDCollateJSON.so

         |--x86

               |--libcom_couchbase_touchdb_TDCollateJSON.so

In my build.gradle, I have mentioned my dependency as -

dependencies {

   

    compile files('libs/native_so_files.jar')

}

Any idea what I am doing wrong ?

[Makoto Yamazaki]

are you sure that content of native_so_files.jar is

|--lib

    |--ameabi

           |--libcom_couchbase_touchdb_TDCollateJSON.so

    |--mips

           |--libcom_couchbase_touchdb_TDCollateJSON.so

    |--x86

           |--libcom_couchbase_touchdb_TDCollateJSON.so

not

|--native-so-files

     |--lib

         |--ameabi

                 |--libcom_couchbase_touchdb_TDCollateJSON.so

         |--mips

                |--libcom_couchbase_touchdb_TDCollateJSON.so

         |--x86

               |--libcom_couchbase_touchdb_TDCollateJSON.so

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
YAMAZAKI Makoto

[Shubham Goyal]

Hey Makoto.  

My native_so_files.jar has this exact structure -

|--lib

    |--ameabi

           |--libcom_couchbase_touchdb_TDCollateJSON.so

    |--mips

           |--libcom_couchbase_touchdb_TDCollateJSON.so

    |--x86

           |--libcom_couchbase_touchdb_TDCollateJSON.so

The exact error I am getting is "java.lang.UnsatisfiedLinkError: Couldn't load com_couchbase_touchdb_TDCollateJSON: findLibrary returned null" .

I am trying to make a shift to Android Studio from eclipse. I also have a jni folder with following contents - 

|--jni

    |--Android.mk

    |--Application.mk

    |--com_couchbase_touchdb_TDCollateJSON.cpp

    |--com_couchbase_touchdb_TDCollateJSON.h

    |--sqlite3.h

Thanks

[Vladimir Zvezda]

Hello, 

On Wed, Dec 25, 2013 at 9:45 PM, Shubham Goyal <shubh...@gmail.com> wrote:

|--lib

    |--ameabi

           |--libcom_couchbase_touchdb_TDCollateJSON.so

    |--mips

           |--libcom_couchbase_touchdb_TDCollateJSON.so

    |--x86

           |--libcom_couchbase_touchdb_TDCollateJSON.so

I think it should be "armeabi", not "ameabi". 

You can also check if the native libraries are in apk file after build. For example, you can change .apk file extension to .zip and view the folder structure like for typical zip archive.

[Shubham Goyal]

Hey Vladimir  

Sorry for the typo. I meant to write armeabi only. 

I looked into my apk file and native libs were not there. I had native_so_files.jar in my library project. I was building the library project and was using the generated aar in my application project (First deploying aar to S3 and then fetching it from there as a dependency). What I did not realize is that gradle was using old dependencies from dependency cache. Once I used --refresh-dependencies with the install , it worked just fine. Thanks for your help.

Shubham

[Xavier Ducrohet]

Version 0.7.2 was published on MavenCentral.

You can put your prebuilts in src/main/jniLibs/...

There's a sample called ndkJniLib that shows the expected folder structure in there.

[Karl Åström]

You mean ndkPrebuilts not ndkJniLib right?

[Johannes Kraemer]

Version 0.7.2 of what? 

Where can we find this sample?

I'd love to use this new feature, but don't understand where do get it.

[Xavier Ducrohet]

Samples are at the bottom of this page: http://tools.android.com/tech-docs/new-build-system

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[mwolfe]

Do we need a product flavor for each ABI? I would much rather bundle all my ABI's in a single product flavor as it's a very small library.

[Xavier Ducrohet]

No you don't need to split per ABI.

You mention libraries. Libraries don't support flavors anyway, so when you publish an aar it's always a fat bundle with all ABIs.

[Mike Kulasinski]

Can you please show an example of build.gradle how it would look like when added native library to a LIBRARY project ?

I have a simple native libarary that sits in the Android-Libarary project and I can't figure out how to add it to gradle, because simple move *.so files to src/main/jniLibs does not work for me.

Thanks

[Moritz Post]

@Mike Kulasinski 

 

I have a simple native libarary that sits in the Android-Libarary project and I can't figure out how to add it to gradle, because simple move *.so files to src/main/jniLibs does not work for me.

There seems to be a bug in the build system in regards to merging when using a library project. If you place your native .so files into the jniLibs folder of the main project the native libraries should be picked up.

Greets

Moritz

[Xavier Ducrohet]

I just pushed 0.8 to Maven Central. This fixes the issue of jniLibs not being supported in library projects.

[Mike Kulasinski]

Thanks will test it on Monday

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/nQobKd2Gl_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Jeff Campbell]

It would still be nice to be able to put my .so files in to a Maven repo and have a dependency like:

compile 'net.sqlcipher:sqlcipher:3.0.0:armeabi'  // <-- note the classifier of "armeabi" (so Android Gradle plugin knows that it is a "armeabi" binary

By supporting this, I would NOT have to commit binaries into my GIT repo.  I could also share my binaries between projects.

[Xavier Ducrohet]

You could put them in an aar. This way if you end publishing both armeabit and x86 you don't have to setup the dependency separately in each flavor.

Yes, it's not great, as you have to create a new archive with your so files, but it's also better, since it would contain an manifest and declare the minSdkVersion of your library.

[Mark Murphy]

On Thu, Jan 23, 2014, at 15:36, Xavier Ducrohet wrote:
> You could put them in an aar. This way if you end publishing both
> armeabit
> and x86 you don't have to setup the dependency separately in each flavor.

Like this proof-of-concept SQLCipher AAR project that I put together
yesterday:

https://github.com/commonsguy/sqlcipher-gradle

It's very much a proof of concept (i.e., YMMV), and hopefully tomorrow
I'll move it to 0.8.+ of the plugin and Gradle 1.10.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_: Version 5.5... And
Still Going Strong!

[Chris Byers]

Thanks Xavier for a great implementation, looks like NDK support is heading in the right direction!

I used your examples to compile an NDK library I have with no issues.  However, one feature request, when you can, is to either allow me to override (or merge) the Android.mk file with my own so that I can fully customize the NDK build, or provide additional library/path linking options.  I need to add "-Wl,-whole-archive path/to/static/lib -wl,-no-whole-archive" to my NDK library as well as link a prebuilt .so library against my NDK library.  I have a custom built arm library for Python (libpython.so) that my NDK code requires linking against, but I don't see an "easy" way to provide a path (-L) for it.

As a work around, I am tagging on to the end of the first ldLibs entry as such in the mean time:

ldLibs "log -lpython -L/Users/my_build/libs/ -wl,-no-whole-archive /Users/my_build/libs/libxml2.a"

I love Android Studio and look forward to full NDK support, thanks for the hard work, it's working quite well already!

[余川]

Hi，Yonnie Lu 

  I  do  it  like  that，bug  the   error  log   is  A problem occurred evaluating root project 'MyApplication2'.

> No signature of method: org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.compile() is applicable for argument types: (org.gradle.api.internal.file.collections.DefaultConfigurableFileTree) values: [directory 'libs']

Possible solutions: module(java.lang.Object)。

If  you  have  time，can  you   help  me？ 

在 2013年6月5日星期三UTC+8下午2时11分30秒，Yonnie Lu写道：

[Roberto Garcia]

I have a set of pre-build JniLibs and I have copied it into my src/main/jniLibs.

I am still not seeing the integration into my final APKs.  When I hand copy the .so files into the build directory per the previous work-around, there is a marked difference in size and my app functions properly.  This does not occur automatically.

My questions are as follows:

1.  If I have a set of pre-build .so libraries, is it enough to simply drop them into my project structure as you have instructed?

2.  Are there any changes to my build.gradle file?

3.  What markers should I expect in the build directory to indicate that the integration is functioning properly?  Should I see a new directory called "native-libs" or is the integration more opaque now?

I believe that my use-case is the simplest of them all, so I am hoping that it will be obvious to someone out there.

Thanks!

Best

Roberto

[Xavier Ducrohet]

src/main/jniLibs should be enough but the .so files in there should be in sub folder named after the device ABIs.

For example:

src/main/jniLibs/armeabi-v7a/libfoo.so

src/main/jniLibs/x86/libfoo.so

src/main/jniLibs/mips/libfoo.so

You shouldn't need to change your build.gradle unless you relocate src/main/jniLibs or you want to select only some ABI for multi-apks.

You can look at the output with unzip -l foo.apk. If you should show the content of your zip which should contain:

lib/armeabi-v7a/libfoo.so

lib/x86/libfoo.so

lib/mips/libfoo.so

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Roberto Garcia]

Thanks!

Do I need the NDK even for this simple case?  If this is the case, then this may be my issue.

You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/nQobKd2Gl_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Roberto Garcia]

Never mind…I answered my own question.  It works exactly as advertised.  Thanks for the help!

[Richard Lucas]

Thank you OP for the post and thank you to everyone who has contributed, it is most helpful.

I believe my folder structure is correct, but I am still getting an error (see below). Is there something I must do after I make the changes so that Gradle recognizes it?

All help is greatly appreciated.

Error:

Error:(9) A problem occurred evaluating root project 'Android-ffmpeg-tutorial01'.

> No signature of method: org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.compile() is applicable for argument types: (org.gradle.api.internal.file.collections.DefaultConfigurableFileTree) values: [directory 'libs']
  Possible solutions: module(java.lang.Object)

[Nirav Shah]

I have followed this process to build the gradle with .so files but it gives error cant load .so files

and i am using .jar file that uses this .so files.

[Thomas Gravina]

Did anyone of you noticed that this process include the .so files twice into the final apk?

I recently switched to Android Studio and started using Gradle to build my Android project and I've got a weird behavior. Basically, I have a lib in app/src/main/jniLibs, divided in two folders: armeabi and armeabi-7va. 
The problem is that since I use Gradle, the APK file is twice more heavier. The reason is that Gradle copy the *.so files twice in the APK at two different locations:
- lib/
- main/jniLibs/

When I used to build using Eclipse, everything was fine, *.so files were copied only one time.

Does anyone know if there is a way to avoid this behavior? Is this a bug in Gradle or am I doing something wrong?

[Alexander Zhigulich]

Amazing! Thanks a lot.

[Paul Wisner]

For me, and I assume lots of other developers, I need to find a way to do this without disrupting a large population of Eclipse ADT users. 

So.... moving files to non-traditional locations is not an option.

-Paul

[gutte57]

Thanks!!!!!!

i was looking for a solution for more than a week now. you are awsome!

[Jacob G]

Hi Thomas,

I also had the same problem, and came up with the same solution as you. I was wondering how can that be if everyone is saying to put it in src/main. I came across your thread here, and I guess I feel better someone else also experienced the same thing. But I'm wondering what is going on that everyone else does it differently. Maybe they don't notice the dupes?

[Xavier Hallade]

Hi,

.so files integration is perfectly supported when the .so's are put under jniLibs/<abi> of any project or library, or integrated through an .aar dependency.

no hacks should be used anymore (since android plugin 0.7 I guess).

integrating .so files from jars this way can indeed lead to duplication issues and other errors.

In the final APK, .so files should be under lib/<abi>. 

main/jniLibs is a proper location for .so files inside the project but absolutely not for .so files inside the APK.

Regards,

Xavier.

[Alex Chang]

Hi, Xavier

I tried the solution which moves all .so files to src/main/jniLibs/armeabi, but it still does not work. When I unzip the generated apk from build/outputs/apk, I don't see any lib directory. Is there any setting I should double check?

I also check your ndkLibPrebuilts sample and directory structures are the same (src/main/jniLibs/armeabi).

My environment:

1. Android studio on a Mac book pro

2. Used a rooted Nexus 5 to test

Thanks

Alex

[Alex Chang]

Hi.

I finally found out why my .so files were not integrated into the apk. 

I specified the following before

jniLibs.srcDirs = ['src/main/jniLibs/armeabi']

Now I specified the following:

jniLibs.srcDirs = ['src/main/jniLibs']

Then it works.

On Friday, February 27, 2015 at 1:30:06 AM UTC-8, Xavier Hallade wrote:

[Rao Saifullah]

Hi Everyone, 

I followed your proposed solution and put all the *.so files in the 'src/main/jniLibs' folder and compiled it successfully and also in 'build/outputs/apk`, i can see the the three .so files in zip file. But when I am porting that program on AVD, it is giving dlopen error. like dlopen failed and can not find XXXXX.so file. The file is present in jniLibs folder. Any help about this. 

[Xavier Hallade]

Did you put your libs inside jniLibs/(armeabi,x86,...) ? What are the target architecture of your libs and the architecture of your AVD ?

[Girdhar G. Patel]

I am getting below errors and app just hangs at launch when trying to load sqlcipher library. I am running on Samsung Nexus S (Android 4.1.2) device which is 32 bit device.

Trying to load lib /data/data/com.welldoc.platform.android/lib/libstlport_shared.so 0x420a3b78

Added shared lib /data/data/com.welldoc.platform.android/lib/libstlport_shared.so 0x420a3b78

No JNI_OnLoad found in /data/data/com.welldoc.platform.android/lib/libstlport_shared.so 0x420a3b78, skipping init

Trying to load lib /data/data/com.welldoc.platform.android/lib/libsqlcipher_android.so 0x420a3b78

Added shared lib /data/data/com.welldoc.platform.android/lib/libsqlcipher_android.so 0x420a3b78

No JNI_OnLoad found in /data/data/com.welldoc.platform.android/lib/libsqlcipher_android.so 0x420a3b78, skipping init

Trying to load lib /data/data/com.welldoc.platform.android/lib/libdatabase_sqlcipher.so 0x420a3b78

Added shared lib /data/data/com.welldoc.platform.android/lib/libdatabase_sqlcipher.so 0x420a3b78

JNI_OnLoad called

JNI_OnLoad register methods

I have tried 2 approaches.

1. have app\src\main\jniLibs folder where my armeabi, armeabi-v7a and x86 olders are present with respective .so files and my assets folder has icudt46l.zip

2. I have archived the armeabi folder to zip named:armeabi.zip with the folder in zip like: lib/armeabi/xxx.so

    Renamed armeabi.zip to armeabi.jar and put armeabi.jar into libs folder with the other jars.

I am getting same error as I mentioned above with both the above approaches which I tried. Any help would be highly appreciated. 

NOTE: when I unzip my .apk file, I can see lib folder with armeabi, armeabi-v7a and x86 sub-folders and .so files inside all of those.