Starting with Android N, the android applications will not be allowed to access any of the shared libraries that are present on the system image. The point is to self contain the android application without depending on the libraries that are present on the device itself. This is great from the point of view of Android and its users but not so great if you are developing an android application, another headache to take care of.
Incase you do try to access the libraries from the application then you would get an error on the following lines –
11-15 00:19:13.733 1561 1561 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: library “/system/lib64/libmynativelib.so” needed or dlopened by “/system/lib64/libnativeloader.so” is not accessible for the namespace “classloader-namespace”
11-15 00:19:13.733 1561 1561 E AndroidRuntime: at java.lang.Runtime.loadLibrary0(Runtime.java:977)
11-15 00:19:13.733 1561 1561 E AndroidRuntime: at java.lang.System.loadLibrary(System.java:1530)
11-15 00:19:13.733 1561 1561 E AndroidRuntime: at com.example.testapp.Test.<clinit>(Test.java:48)
We can solve this issue in two ways –
1) If you are developing an application using Android Studio then make all your libraries self contained inside the apk, just add a jni folder in the android app folder structure and place the libs in that.
2) If you are building it via AOSP build using Android.mk files then I haven’t found a way to make it a part of the APK since in this build approach no matter what you do the libraries don’t get included inside the APK. Since we have control over the system image (Because you are building the AOSP image) change the file – “public.libraries.txt” to include all the libraries that you want to be exempted from this rule. This file should be present in “/etc/” or “/vendor/etc/”
References –
1) http://android-developers.blogspot.in/2016/06/improving-stability-with-private-cc.html
2) https://source.android.com/devices/tech/config/namespaces_libraries.html
Broken Funny Bone; 