64 bit - how to use 32bit native libraries on 64 bit Android-L platform

Question

I have a Android application which i compiled with AOSP(Kitkat) as android system application and it was running fine. My application is dependent on native code compiled with Android-NDK as 32 bit libraries. I am copying native libraries inside my android applications libs/armeabi folder and then building my android application in AOSP(I have also modified device.mk to copy my libs in the /system/lib folder). Everything is working fine on Android Kitkat.

When i ported my application on Android-L(64bit platform) then i am not able to load my native libraries from Android application and error is like -

java.lang.UnsatisfiedLinkError: dlopen failed: "libfoobar.so" is 32-bit instead of 64-bit

I am using following java code to load native library-

        if ( ENABLE_ANDROID_INTEGRATION )
        {
            System.load("/system/lib/libfoobar.so");
        }
        else
        {
            System.loadLibrary("foobar");
        }

When i am building my code with AOSP then ENABLE_ANDROID_INTEGRATION is true

More interestingly when i turned off ENABLE_ANDROID_INTEGRATION and build my application in Eclipse, outside AOSP as a normal "downloadable" application then my application is running fine on 64bit Android platform.

What i want to know - how can i build my application as a native android system application with 32 bit libraries(that means AOSP build) for 64 bit Android platform?

What i have tried - I used LOCAL_32_BIT_ONLY = true flag in my android application's Android.mk file, but it seams it is not useful. May be i am not fully aware of this flag use.

As i am running out of time so i preferred to post this question here in group instead of RnD. If anyone faced this problem then please guide.

Regards, Meraj

Answer 1

The reason why it works when installed as a third party application, is that on installation, the package manager scans the APK and checks if it uses native libraries, and if such are found, it stores which ABI they used (since it only installs libraries for one single ABI, so the info about which choice was made needs to be stored somewhere).

For an application that is installed system wide with the libraries in /system/lib, it's not clear that this particular application depends on some app specific libs in /system/lib (that aren't available in a 64 bit version in /system/lib64), so the package/application manager can't know that this particular app requires a specific ABI and thus runs it in 64 bit mode.

Setting LOCAL_32_BIT_ONLY probably only affects whether it should be compiled in 32 bit mode, not in which way it should be run.

An old (and probably outdated) report at http://www.slideshare.net/hidenorly/investigation-result-on-64-bit-support-in-aosp seems to suggest that the native libraries for apps should go into /system/lib/apkname, but this doesn't seem to be true on an actual Android 5.0 system. Instead, the libs seem to be in /system/app/appname/lib/abiname. Some apps seem to have native libs for multiple architectures (e.g. both "arm" and "arm64" as abiname), while others only have one single architecture (which would force the process to be started in that ABI mode).

So I think you need to alter the mechanism for how you install your native libraries (you said you manually modified device.mk) - I'm not familiar with how to build own apps as part of an AOSP build, but I'd recommend trying to look at the existing bundled apps how they do it, this commit may be related: https://android.googlesource.com/platform/packages/apps/Terminal/+/1a161f75%5E%21/