SoLoader can't find .so deps when app is packaged as Prebuilt APK with Android AOSP Source about soloader

[hhff]

Cool yeah. I have a feeling that "permission denied" is actually because the file doesn't exist. I'm still working on this, but when I solve it I'll come back and update this issue to help anyone else who comes this way.

[hhff]

hi @SergiiGudym - yup I did. So - for anyone else:

If you're embedding your APK into a AOSP build that will packaged with the ROM, it's important to note a few things:

• the APK isn't going to go through an "Install" process (like it would via ADB or any other traditional install process). As part of that normal install process, packaged, prebuilt libs will be extracted and moved to the appropriate place for the APK to require them. This doesn't happen when packaging the APK with AOSP.

• an APK is basically a fancy zip file, and those static libs are inside.

---

So - when you're packaging your React Native app with an AOSP ROM, you'll need to do the following:

1. Do all of the normal setup you would with a standard APK that you're building with AOSP (some googling will help with this)

2. Unzip your APK:

mkdir ./unzipped && unzip ./MyAPK.apk -d ./unzipped

3. Move your static libs to the same level as your Android.mk (assuming you're building for both architectures as per react native default)

mv ./unzipped/lib/armeabi-v7a ./lib
mv ./unzipped/lib/x86 ./lib64

4. Edit your Android.mk file to move these libs during AOSP build time:

LOCAL_PATH := $(call my-dir)

# Example for 32 bit deps
include $(CLEAR_VARS)
LOCAL_MODULE := libfb
LOCAL_SRC_FILES := lib/libfb.so
LOCAL_MODULE_TAGS := optional
LOCAL_MULTILIB := 32
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_PATH := $(PRODUCT_OUT)/vendor/lib
include $(BUILD_PREBUILT)

# Example for 64 bit deps
include $(CLEAR_VARS)
LOCAL_MODULE := libfb
LOCAL_SRC_FILES := lib64/libfb.so
LOCAL_MODULE_TAGS := optional
LOCAL_MULTILIB := 64
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_PATH := $(PRODUCT_OUT)/vendor/lib64
include $(BUILD_PREBUILT)

# ^^At the time of writing, React Native has like ~11 static libs, so you'll have ~22 of these blocks

# Finally, declare the APK itself
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE := MyAPK
LOCAL_SRC_FILES := $(LOCAL_MODULE).apk
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_CERTIFICATE := platform
LOCAL_PRIVILEGED_MODULE := true
include $(BUILD_PREBUILT)

5. Now when you build AOSP, flash the device, and run MyAPK, SoLoader should be able to find and link these libs at runtime.

---

Some gotchas:

• The Android.mk file is super finicky. Make sure you don't have any extra spaces at the end of lines, etc. Seriously! It can crash an AOSP build.
• Remember your static libs may change if your build does (Upgrading react native, etc). We've setup a shell script to pull in the latest APK from an s3 bucket, and automate most of the above. Then when we're about to check in the new version of the APK, we'll see any libs were added. If so, we'll add a block for them in the Android.mk before committing.
• Hit me with any more questions!

[hhff]

Oh - and some extra context:

I've tried unpacking all of the .so files from the APK, and adding them as prebuilts to the AOSP build process, like so (via the Android.mk file):

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libreactnativejni
LOCAL_SRC_FILES := libreactnativejni.so
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_TAGS := optional
include $(BUILD_PREBUILT)

and adding

LOCAL_REQUIRED_MODULES := libfb libfolly_json libglog_init libglog libgnustl_shared libicu_common libimagepipeline libjsc libprivatedata libreactnativejni libyoga

to the prebuilt block itself

but to no avail.

[passy]

Sadly, this is way out of my comfort zone, so I can't give you any good advice here but the main issue appears to be

Error when loading lib: dlopen failed: couldn't map "/data/data/com.lightos/lib-main/libgnustl_shared.so" segment 2: Permission denied

I'm not sure if there are certain filesystem/mount flags that would prevent mapping the file from that location or if it's a security restriction in the Android runtime only allowing dlopen from application-specific paths.

Googling for "dlopen failed: couldn't map" brings up a lot of Android-related issues, but nothing particularly actionable. Others have suggested copying the files to an application-private location. Perhaps you could do that as a workaround on startup.

[SergiiGudym]

Hi. Did you fix it?

[hhff]

@passy this can be closed, fwiw. Thought i'd leave it open in case anyone has more questions!

[ozymand1as]

@hhff Is there anything else that has to be done? I've added everything to Android.mk, but my app still doesn't run and the libraries don't even appear in the target folder.

[ozymand1as]

It seems that it's also necessary to add all the libraries to your app's module in Android.mk with LOCAL_SHARED_LIBRARIES.
So, in my Android.mk app is declared like this:

#all .so libraries declared there ^^^

include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE := <Module name>
LOCAL_CERTIFICATE := platform
LOCAL_SRC_FILES := <apk file>
LOCAL_MODULE_CLASS := APPS
LOCAL_PRIVILEGED_MODULE := true
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_SHARED_LIBRARIES := libfb libfolly_json libglog_init libglog libgnustl_shared libicu_common libimagepipeline libjsc libprivatedata libreactnativejni libyoga
include $(BUILD_PREBUILT)

[hhff]

Cool thanks @ozymand1as ! FWIW - I didn't have to do that, but it's likely we're running different versions of AOSP so perhaps thats the reason

[simpleton]

Version 0.10.3 has been released which includes this fix.