0

Our app supports 7 different architectures. We have a native library which we are using in our java code. When we build a single APK its size reach the 50MB limit because we have 7 instances of the native library packed into the APK. Each instance of the library after compilation is about 10MB.

We don't want to use the multiple APKs method to solve it because it's hard to manage more than 1 APK.

We thought to use the expansion method but we don't know if it possible. We want to pack all the native libraries in a zip and upload it as an expansion to google and then in runtime to use the loadLibrary method in order to load the appropriate library. Does it possible?

Feel free to suggest any other solution that you think it might be suitable.

Thanks.

Sagi Kovo
  • 120
  • 1
  • 5
  • i think you will find something helpful here ==> http://stackoverflow.com/questions/6857807/is-it-possible-to-dynamically-load-a-library-at-runtime-from-an-android-applicat – Aiyaz Parmar Apr 30 '15 at 14:06
  • in the doc a bunch of ways how to deal with it. Each of the ways is suitable for one app and harmful for another. depends on many things in the app and here you will receive opinion-based answers which might not be useful for particular case. http://developer.android.com/google/play/expansion-files.html – Yurets Apr 30 '15 at 14:24
  • @AiyazParmar We don't have a java library. We have a native library coded in C++ and a JNI layer. So this method won't work in our case. – Sagi Kovo Apr 30 '15 at 14:36

2 Answers2

0

I don't think it is possible to call loadLibrary on a .so that is not in the app's apk or on the device (expansions included).

What you can do, though, is include your .so libraries inside an expansion file, create a Starter activity that extracts these SO to a system path on first run, then start your application, invoking:

 System.loadLibrary("/path/to/your/lib/yourlib.so");

You can use the assets folder, treat the .so as an asset, and extract it to the given path.

You can create SOLoaderActivity, which becomes the Activity launched by your app. On first run, the activity extracts the .so, and writes a preference to SharedPreferences. After that, it just checks the preference and launches your other Activity if the pref is set.

I'm not sure how loadLibrary handles full paths, but System.load can do it.

Robin Eisenberg
  • 1,836
  • 18
  • 26
0

I believe this will not be prudent to pack all different .so files into one zip. You can choose to download, unpack, and load only one relevant library - all at runtime.

But managing "multiple apks" is not a big deal, if you automate their build, like described here.

Community
  • 1
  • 1
Alex Cohn
  • 56,089
  • 9
  • 113
  • 307