Can't load libraries that are in dynamic feature modules

[DSteve595]

I'm trying to include a React Native activity in a dynamic feature module. It works when it's included in the base APK, but it looks like some hackery is needed when loading native libraries that are in an installed dynamic feature module: SplitInstallHelper.loadLibrary() should be used on 26+ rather than System.loadLibrary(). Currently I'm getting a crash saying the native library couldn't be found, and this seems like the most likely culprit.
Since SoLoader is the one making the actual call, I'm not sure how I could do that from my end. I tried using sSystemLoadLibraryWrapper, but it looks like my loadLibrary() never gets called.

[icerfish]

I think this might also be related to an issue I am having with Fresco and AppBundles

facebook/fresco#2253

[DSteve595]

Thanks so much!

[erksch]

@DSteve595 How did you resolve the issue?

[DSteve595]

@DSteve595 How did you resolve the issue?

It was resolved by #26.

[erksch]

So you are using the patched So loader from @nesterov-n? Because the fix wasn't merged as I see it.

[DSteve595]

It was merged. See c7980fc

[erksch]

Weird, it doesn't work for me. The SoLoader does not find the native libraries:

D/SoLoader: About to load: libjscexecutor.so
D/SoLoader: libjscexecutor.so not found on /data/data/<package>/lib-main
D/SoLoader: libjscexecutor.so not found on /data/data/<package>/lib-0
D/SoLoader: libjscexecutor.so not found on /data/data/<package>/lib-1
D/SoLoader: libjscexecutor.so not found on /data/app/<package>-LxW4qT73Kp0GBM4oUp20OQ==/lib/arm64
D/SoLoader: libjscexecutor.so not found on /vendor/lib
D/SoLoader: libjscexecutor.so not found on /system/lib
E/SoLoader: couldn't find DSO to load: libjscexecutor.so result: 0

The native libraries are actually located in

/data/data/<package>/files/splitcompat/3/native-libraries/dynamicfeature.config.arm64_v86/

But the SoLoader does not seem to pick up this path. I wonder why it would work for you if your libs are in the same location.

I guess this is where SplitInstallHelper.loadLibrary() would search for.

[erksch]

I found that the error is actually not that the files are in a different place, but that applicationInfo.splitSourceDirs or even applicationInfo.splitNames is null. Even when the dynamic feature is properly installed. This way the implementation of #26 can't pick up the libraries properly. But I wonder what causes that the splitSourceDirs property is not set correctly. Using SplitInstallHelper.updateAppInfo() after installation does not help.

[bembem1011]

I met same problem, when apply dynamic module using React Native activity :(

[erksch]

@bembem1011 do you have the same problem that splitSourceDirs is null? I wrote a patched SoLoader that also looks in /data/data/<package>/files/splitcompat/x/native-libraries for libraries maybe you could try that out.

[bembem1011]

I haven't found the rootcause yet, but if you can share it with me, �I want to try out :( thanks you very much

[erksch]

You can use my fork of SoLoader on the develop branch, build it and include the AAR in your project and see if it works.

Should be something like

dependencies {
      ...
     implementation ('com.facebook.react:react-native:+') {
          exclude group: 'com.facebook.soloader', module: 'soloader'
     }
     implementation name: 'soloader', ext: 'aar'
}

repositories {
      flatDir {
           dirs 'libs'
      }
}

[bembem1011]

thanks @erksch today I will try your patch

[bembem1011]

thanks @erksch you save my life. Your patch is work well, however I haven't understood deeply yet. When I read the debug log, I see splitResourceDirs is not null. However, the soloader cannot load the library correctly without your patch.
The default code (above your code patch)

              if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP
                  && context.getApplicationInfo().splitSourceDirs != null) {
                Log.d(TAG, "adding backup sources from split apks");
                int splitIndex = 0;
                for (String splitApkDir : context.getApplicationInfo().splitSourceDirs) {
                  ApkSoSource splitApkSource =
                      new ApkSoSource(
                          context,
                          new File(splitApkDir),
                          SO_STORE_NAME_SPLIT + (splitIndex++),
                          apkSoSourceFlags);
                  Log.d(TAG, "adding backup source: " + splitApkSource.toString());
                  backupSources.add(splitApkSource);
                }
              }

    2021-02-21 04:25:03.016 16635-16635/com.company.myapp D/SoLoader: adding application source: com.facebook.soloader.DirectorySoSource[root = /data/app/com.company.myapp-F73hOhmdUiA3L91mlttZLw==/lib/arm64 flags = 0]
    2021-02-21 04:25:03.017 16635-16635/com.company.myapp D/SoLoader: adding backup source from : com.facebook.soloader.ApkSoSource[root = /data/data/com.company.myapp/lib-main flags = 1]
    2021-02-21 04:25:03.017 16635-16635/com.company.myapp D/SoLoader: adding backup sources from split apks
    2021-02-21 04:25:03.017 16635-16635/com.company.myapp D/SoLoader: adding backup source: com.facebook.soloader.ApkSoSource[root = /data/data/com.company.myapp/lib-0 flags = 1]
    2021-02-21 04:25:03.017 16635-16635/com.company.myapp D/SoLoader: adding backup source: com.facebook.soloader.ApkSoSource[root = /data/data/com.company.myapp/lib-1 flags = 1]
    2021-02-21 04:25:03.017 16635-16635/com.company.myapp D/SoLoader: adding backup source: com.facebook.soloader.ApkSoSource[root = /data/data/com.company.myapp/lib-2 flags = 1]

[varunon9]

@erksch @bembem1011 might be a silly request but can you share soloader.aar file? I am facing the same issue and want to try this solution.

[fcduarte]

You can use my fork of SoLoader on the develop branch, build it and include the AAR in your project and see if it works.

Should be something like

dependencies {
      ...
     implementation ('com.facebook.react:react-native:+') {
          exclude group: 'com.facebook.soloader', module: 'soloader'
     }
     implementation name: 'soloader', ext: 'aar'
}

repositories {
      flatDir {
           dirs 'libs'
      }
}

@erksch this should be incorporated on the main SoLoader, I don't feel the current version can handle "splitcompat" folders given the amount of issues the community have, just search for "android app bundles java.lang.UnsatisfiedLinkError: couldn't find DSO to load" and most people will be stuck in the same problem.

[belemaire]

@erksch Thanks much for this patch, we were facing the same issue and it did its magic 👍
Any reason why you didn't opened a PR to have this patch in a next SoLoader release ?
Given the amount of users now reporting their problem being fixed by your patch, it would make sense.

[erksch]

@fcduarte @belemaire I'm glad my patch worked for you. I can open a PR, but I think my addition is kind of hacky and maybe needs some polishing before going into the main branch. My fix worked for my problem and has some assumptions where the files will be without actually knowing why, but seeing that it solves the problem for multiple people I'll open a PR.

[erksch]

@varunon9
I uploaded the AAR here.
But building it from source is not that difficult.