missing libnode.so for arm64-v8a

[mohsenoid]

Thanks for the library,

I was trying to replace it with AndroidJSCore but I was not able to run the app cause my device is an arm64 and during runtime, I get couldn't find "libnode.so" error.

I checked the repo and "libnode.so" is missing in node prebuild deps folder for arm64: https://github.com/LiquidPlayer/LiquidCore/tree/master/deps/node-8.9.3/prebuilt

any solution?

Update: I downgraded to v0.2.2 and it was there before!! any reason for removing it?

[ericwlange]

You should be able to use the armeabi-v7a version on arm64, but I may have done something wrong. I removed it only because it made the library enormous to have too many platforms. React Native, for example, only supports x86 and armv7, and it works on all (or mostly all) devices. But I may have configured the library incorrectly. I'll look into it.

[tyler-whitman]

Try adding this in your build.gradle and I believe the issue will be fixed.

defaultConfig { ndk { abiFilters "armeabi-v7a", "x86" } }

This will ensure that on an arm64 device the armeabi-v7a so is used. This is what React Native does.

[mohsenoid]

Thanks for the solution, but this library is not my only native library and others use arm64 and I cannot force my app to skip arm64. if x86 was missing, it was possible but not with arm64.

[ericwlange]

@twhit093 <-- this is the correct solution for most cases.

@mirhoseini <-- I can build the arm64 + x86_64 prebuilts this weekend, but I will probably opt to leave them out of the release builds. You can use your own compiled version.

[ericwlange]

One hack you can try in the meantime -- just copy the armv7 libraries into the arm64-v8 directory. I think it will work, but not 100% sure.

[mohsenoid]

I tried this solution but they are different CPU architectures and I received a runtime error.

[ericwlange]

As promised the 64-bit libraries are there and tested now. I have disabled them by default, but you can enable them by building LiquidCore from head, but uncomment two lines in LiquidCoreAndroid/build.gradle:

        ...
        externalNativeBuild {
            cmake {
                cppFlags "-std=c++11 -fexceptions"
                abiFilters "x86", "armeabi-v7a" //, "x86_64", "arm64-v8a" <-- remove this comment!
            }
        }
        ...

and

    ...
    splits {
        abi {
            enable true
            reset()
            include 'x86', 'armeabi-v7a' //, 'x86_64', 'arm64-v8a' <--- And this one!
            universalApk true
        }
    }
    ...

[mohsenoid]

Thank you so much for your perfect support, I will give it a try.

[mohsenoid]

I cloned the repo and rebuilt aar using changes you mentioned and now it works like a charm. Thanks again for the library and your support.

[CCorrado]

The Pixel 2 requires 'arm64-v8a' to be supported... getting the libnode.so error now.

Is there any reason we can't put this back into the next version? I could rebuild your library to include it using the steps above, but I'm not sure I see why it was removed if flagship devices are not supported.

[ericwlange]

I didn't realize that the Pixel 2 requires it. The only reason I left out 64-bit support by default is that it makes the library very large and had historically not been required. Let me investigate this requirement and I can put it back in by default. It just means that developers should use APK splits when deploying.

[mohsenoid]

I also had the same problem with other libraries either. Good news is arm64 can use old library, but it doesn't work other way. Solution is removing all arm64 instance of your .so libraries from the app so OS get forced to use old ones. add these lines to your build.gradle:

buildTypes {
    debug {
        ....
        ndk {
           abiFilters "armeabi-v7a"
       }

and remove these lines:

splits {
    abi {
        enable true
        reset()
        include 'armeabi-v7a'
        universalApk true
    }
}

[CCorrado]

I thought I remembered reading the v8 and v7 were cross compatible. Thanks! I plan on playing with this today and like I said, I could compile an aar manually...but the Pixel 2 is a flagship. I think there are also issues on a GS8, since it also is v8.

@mohsenoid Wouldn't that Gradle config cause problems with other arhcs like x86?

[mohsenoid]

Almost all recent Android phones are arm64! and you can also add x86 to this abiFilters :) just filter out arm64s

[consp1racy]

While it works now, removing all 64-bit libraries from the APK may not be a viable workaround in the nearing future.

Improving app security and performance on Google Play for years to come

19 December 2017

[...]

• In August 2019, Play will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions.

[...]

64-bit support requirement in 2019

[...]

In anticipation of future Android devices that support 64-bit code only, the Play Console will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions. This can be within a single APK or as one of the multiple APKs published.

We are not removing 32-bit support. Google Play will continue to support 32-bit apps and devices. Apps that do not include native code are unaffected.

Source: https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html

Also, React Native has an open issue concerning missing 64-bit support: https://github.com/facebook/react-native/issues/2814

it made the library enormous to have too many platforms

Release everything, leave it on the consumer to strip out versions they don't need (the process is described in https://github.com/LiquidPlayer/LiquidCore/issues/40#issuecomment-383016447).

[ericwlange]

I will create the fat bundle for the next release. At the moment, I am on the precipice of having a working iOS version (much bigger undertaking than one might imagine), so I am preoccupied by that. But will do this.

[ericwlange]

These are now included by default starting with 0.5.0-experimental-4.