-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
missing libnode.so for arm64-v8a #40
Comments
You should be able to use the |
Try adding this in your build.gradle and I believe the issue will be fixed.
This will ensure that on an arm64 device the armeabi-v7a so is used. This is what React Native does. |
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. |
@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. |
One hack you can try in the meantime -- just copy the |
I tried this solution but they are different CPU architectures and I received a runtime error. |
64-bit node libraries are now built and included in prebuilt, with snapshots Disabled in the library by default
As promised the 64-bit libraries are there and tested now. I have disabled them by default, but you can enable them by building
and
|
Thank you so much for your perfect support, I will give it a try. |
I cloned the repo and rebuilt |
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. |
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. |
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:
and remove these lines:
|
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? |
Almost all recent Android phones are arm64! |
While it works now, removing all 64-bit libraries from the APK may not be a viable workaround in the nearing future.
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: facebook/react-native#2814
Release everything, leave it on the consumer to strip out versions they don't need (the process is described in #40 (comment)). |
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. |
Now using LiquidCoreCommon code in Android
These are now included by default starting with 0.5.0-experimental-4. |
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?
The text was updated successfully, but these errors were encountered: