Understanding of the armeabi & armeabi-v7a folders during app install

363 views
Skip to first unread message

Akshat Jain

unread,
Apr 15, 2015, 8:46:13 PM4/15/15
to andro...@googlegroups.com, Pranav Konduru
Hello everyone,

We have few native libraries in our application and we want to avoid duplication of libraries unless they are specific to v7a platform(thus reducing the apk size significantly).

The NDK documentation says that the following:

Automatic extraction of native code at install time

When installing an application, the package manager service scans the APK, and looks for any shared library of the form:

     lib/<primary-abi>/lib<name>.so

If none is found, and a secondary ABI is defined, the service scans for shared libraries of the form:

    lib/<secondary-abi>/lib<name>.so

When it finds libraries that it's looking for, the package manager copies them to /lib/lib<name>.so, under the application's data directory (/data/data/<package_name>/lib/). If there is no .so file, the application builds and installs, but crashes at runtime.

This mechanism ensures that the system extracts the best machine code from the package at installation time.


but from our findings, it seems to contradict the above claims.

Here is the library structure:

libs/
   armeabi/
          libsslsdk.so
          liblogger.so      ( this depends on the liblog4cpp.so)
          liblog4cpp.so    
          libPDFNet.so  (~6MB and 3rd party )
          libcrypto.so
   armeabi-v7a/
          libsslsdk.so   (v7a version)
          liblogger.so
          liblog4cpp.so
          libcrypto.so  (v7a version)


Here are the things we tried on a arm-v7a device (nexus 5)

1. We kept the libPDFNet.so to just the armeabi folder (as per the above NDK doc) and our app crashed when it tried load the library. The /data/app-lib/<appname> folder  showed only the above 4 libraries and not the libPDFNet.so present.

2. We removed the armeabi-v7a folder completely  and just kept the armeabi folder (with replaced v7a files), the app worked flawlessly.

3. We removed armeabi and kept only armeabi-v7a folder (with the pdfnet.so copied). The app worked flawlessly (this is as expected).

4.  We removed  liblog4cpp.so from the armeabi-v7a folder ( but it was present in the armeabi folder) and launched the app.  The /data/app-lib/<appname>  folder showed 4 files again, the liblog4cpp.so was present there. I think that since the liblog.so has a linked refernce to liblog4cpp.so, android Packagemanager copied that file from the armeabi folder to the extracted folder. But it did not copy the libPDFNet.so.


Now my question is : 

1. Why are all the behaviors different and not consistent with the documentation ? ( or maybe the documentation refers to dynamically referenced binaries only )

2. How do we achieve similar behavior for the libPFDNet.so, so that we only maintain one copy of it and it gets extracted to the app-lib folder by PackageManager ?

3. Will keeping multiple APKs for each architecture be advised ?


Thanks,

Akshat



Reply all
Reply to author
Forward
0 new messages