React-native: React-native integreted into existing android apk is giving crash in Asus Zenphone 5. react-native version used : 0.19

[anishakd4]

java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app-lib/com.caratlane.android-1/libreactnativejni.so" has unexpected e_machine: 40
E/AndroidRuntime(31481): at java.lang.Runtime.load(Runtime.java:333)
E/AndroidRuntime(31481): at java.lang.System.load(System.java:512)
E/AndroidRuntime(31481): at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
E/AndroidRuntime(31481): at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:209)
E/AndroidRuntime(31481): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:178)
E/AndroidRuntime(31481): at com.facebook.react.bridge.NativeMap.(NativeMap.java:23)
E/AndroidRuntime(31481): at com.microsoft.codepush.react.CodePushPackage.getCurrentPackageInfo(CodePushPackage.java:72)
E/AndroidRuntime(31481): at com.microsoft.codepush.react.CodePushPackage.getCurrentPackageFolderPath(CodePushPackage.java:91)
E/AndroidRuntime(31481): at com.microsoft.codepush.react.CodePushPackage.getCurrentPackageBundlePath(CodePushPackage.java:101)
E/AndroidRuntime(31481): at com.microsoft.codepush.react.CodePush.getBundleUrl(CodePush.java:140)
E/AndroidRuntime(31481): at com.caratlane.android.Activity.HomePageActivity.onCreate(HomePageActivity.java:93)
E/AndroidRuntime(31481): at android.app.Activity.performCreate(Activity.java:5411)
E/AndroidRuntime(31481): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
E/AndroidRuntime(31481): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2270)
E/AndroidRuntime(31481): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2396)
E/AndroidRuntime(31481): at android.app.ActivityThread.access$800(ActivityThread.java:139)
E/AndroidRuntime(31481): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1293)
E/AndroidRuntime(31481): at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(31481): at android.os.Looper.loop(Looper.java:149)
E/AndroidRuntime(31481): at android.app.ActivityThread.main(ActivityThread.java:5257)
E/AndroidRuntime(31481): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(31481): at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime(31481): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
E/AndroidRuntime(31481): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:609)
E/AndroidRuntime(31481): at dalvik.system.NativeStart.main(Native Method)

[facebook-github-bot]

Hey anishakd4, thanks for reporting this issue!

React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.

• If you don't know how to do something or something is not working as you expect but not sure it's a bug, please ask on StackOverflow with the tag react-native or for more real time interactions, ask on Discord in the #react-native channel.
• If this is a feature request or a bug that you would like to be fixed, please report it on Product Pains. It has a ranking feature that lets us focus on the most important issues the community is experiencing.
• We welcome clear issues and PRs that are ready for in-depth discussion. Please provide screenshots where appropriate and always mention the version of React Native you're using. Thank you for your contributions!

[mkonicek]

Are you running a release build for ARM devices on an x86 device by chance? You can check this by unzipping your .apk file and checking the libs/x86 folder. It should be present and contain .so files.

[esutton]

I did not know Android was running on x86 devices but the Zenphone 5 is one.

https://www.asus.com/Phone/ZenFone_5_A500CG/

Chipset Intel Atom Z2580
CPU Dual-core 2.0 GHz
GPU PowerVR SGX544MP2

[anishakd4]

@mkonicek Asus Zenphone 5 is x86 device. I generated 3 release builds : x86 release apk, ARM release apk and universal apk. Universal apk is giving above mentioned crash in Asus zenphone 5(x86 device).

[anishakd4]

Yeah @esutton Asus phones are powered by INTEL. x86 release apk works fine on ASUS phone. But i don't want to use split android apks. I thought universal apk should run on both "ARM" and "x86" devices.

[anishakd4]

@mkonicek and @esutton can you suggest something. My company has fixed release date in next week. Can universal apk run on both "ARM" an "x86" platform??

[mkonicek]

The universal APK should work on x86 devices although I haven't tested it on an x86 device.

Can you try disabling the split APK builds in your build.gradle? https://github.com/facebook/react-native/blob/master/local-cli/generator-android/templates/src/app/build.gradle#L71

That way you should get only one APK, is it any different from the universal one?

[anishakd4]

@mkonicek universal apk gives crash on ASUS phone(intel powered x86 devices) . Only split apks based on CPU architecture works fine. I have already tried by disabling split apk.

[mkonicek]

@anishakd4 Are you saying the x86 APK works fine for you? In that case you can publish two APKs to the Play Store - ARM, x86 (and don't publish the universal APK). Everything should be fine then. Correct?

[anishakd4]

@mkonicek Yeah thats ok I can ship two APKs. But universal APK should work on both the platforms. We already have two Apps like facebook and messenger for my company. Now if I ship two APKs then it would mean that I will be shipping four APKs for each release. So can you confirm by trying yourself whether universal APK works in ASUS phone or not??

[mkonicek]

I agree the universal APK should work on x86 phones although I don't have an Asus phone so not sure this bug is specific to Asus. Do you know if the same issue occurs on other x86 phones by chance?

I'm swamped by several other things but long term we should either figure out how to make the universal APKs work on all phones or always build split APKs. If anyone has bandwidth to look into this that would be awesome! A workaround for now would be to ship those two APKs for each of your apps :(

@corbt I think you've run into some issues with x86 devices in the past?

[corbt]

@mkonicek no, I've worked with arm64 devices but not x86 (#2814). It doesn't sound to me like this bug is related, although I can't be sure.

@anishakd4 does your app have other native code/dependencies as well? If you can figure out exactly what combination of native dependencies causes this issue, that may help. Is it possible to reproduce with an emulator?

[mkonicek]

Ah OK, thanks for looking @corbt!

[devonEdison]

need help from @corbt

[anishakd4]

@corbt and @mkonicek I created a basic app as mentioned in react-native getting started website, and it is not working in Asus Zenphone 5.

[devonEdison]

@corbt and @mkonicek i use ASUS_T00F , android 4.4.2 and it's not working.

[corbt]

Hmm @anishakd4 that's a bad sign. Would you mind trying to download/run the Facebook Groups app from the Play Store on your Asus Zenphone 5? That's a production Facebook app built with React Native, so that should give us an idea if the problem is a fundamental problem with the way RN for Android is currently packaged or just a misconfiguration/3rd party compatibility issue.

[devonEdison]

hi @corbt , i used ASUS_T00F , android 4.4.2 and it's working with the Facebook Groups app, I downloaded from the Play store, and the version is 50.1.0.50.78

[anishakd4]

@corbt , @devonEdison and @mkonicek Facebook Groups app is using split apks based on CPU architecture thats why it is working. My issue is still the same that universal apk should work on x86 and arm devices both but it is not working on ASUS Zenphone 5 mobile. If you extract the Facebook Groups apk file then you will see that they are using split apks based on CPU architecture.

[corbt]

ok @anishakd4 that's right, I forgot that you mentioned that earlier. At least there's a workaround then (using split builds). Since neither myself nor anyone in this thread has access to a Zenphone 5, it would be good if you could figure out what needs to be changed to make universal builds work on x86, and then we can talk about merging it. Sorry that I've got nothing more concrete.

[guyca]

@anishakd4 Maybe this issue is related to https://commonsware.com/blog/2013/11/21/libhoudini-what-it-means-for-developers.html? x86 contain a binary translator component called Houdini which translats arm binaries to x86 binaries.
IIRC, if there are more arm libraries in your project then x86 libs - when you run your app Houdini will try to translate the arm SO files instead of loading the generated x86 build. The workaround is to add dummy x86 SO files.
https://software.intel.com/en-us/forums/android-applications-on-intel-architecture/topic/518471

[anishakd4]

@guyca , @corbt , @mkonicek and @devonEdison if we extract an react-native universal apk then in lib folder we can see two folders "x86" and "arm" folder. Each folder is having its own "SO" files. I think the issue for the crash is that in case of universal apk the mobile is by default always using "arm" folder "SO" files rather then using "x86" folder in case of intel powererd phones. If anyone wants to see the universal apk then he can install "CaratLane" app from play store and then take out the apk file from his mobile. "CaratLane" is using react-native for its HomePage.

[mkonicek]

Hi there! This issue is being closed because it has been inactive for a while.

But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/react-native-integreted-into-existing-android-apk-is-giving-crash-in-asus-zenphone-5-react-native-version-used-019

ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub. GitHub issues have voting too, nevertheless
Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top

Also, if this issue is a bug, please consider sending a pull request with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

[felipecsl]

We're having exactly the same problem described by @anishpCL. Did anyone figure out how to fix this with the "dummy x86 SO files" workaround, or you're doing split APKs?
We wanted to avoid that at all costs, just as a last resort.

[lyahdav]

I did some research on this issue today. My best guess as to underlying issue is a problem with the ARM .so files provided by React Native when translated through Houdini (the ARM to x86 translator):

10-22 18:33:41.423 16430-16430/? D/houdini: [16430] Loading library(version: 4.0.8.45720 RELEASE)... successfully.
10-22 18:33:41.423 16430-16430/? D/houdini: [16430] Unsupported feature (ID:0x10600cae).
10-22 18:33:41.423 16430-16430/? D/houdini: [16430] Open Native Library /data/app-lib/com.emptyrnproject-1/libreactnativejni.so failed.

The key error message is Unsupported feature (ID:0x10600cae). I did a bit of Googling for it but could not understand what the error means. Perhaps there is some ARM feature that the compiled .so files leverage that Houdini doesn't know how to translate?

If someone else wants to investigate further, there's a straightforward way to reproduce this on a Mac without needing to get your hands on an Android x86 device:

1. Install the BlueStacks Android emulator. This emulator supports Houdini.
2. Create a new React Native project.
3. Remove "x86" from the abiFilters property in the build.gradle file.
4. Once you have the BlueStacks emulator running, you can run the project from Android Studio and it will let you choose to launch it in the BlueStacks emulator.
5. You will see the Houdini error message above in logs (careful, that error is only at debug level if you're filtering). You will also see these errors:

dlopen failed: "/data/app-lib/com.emptyrnproject-1/libreactnativejni.so" has unexpected e_machine: 40
com.facebook.soloader.SoLoader$WrongAbiError: APK was built for a different platform

I even tried the workaround of adding dummy x86 SO files but I got another error message in that case: java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app-lib/com.emptyrnproject-1/libreactnativejni.so" is too small to be an ELF executable. Perhaps I didn't understand how to correctly perform this workaround. What I did was add an x86 folder in the APK lib folder that matches the exact files in the armeabi-v7a folder but they were all zeroed out (hence that error message). It seems when there is an x86 folder it will just try to load those .so files so I'm not sure this workaround gives us what we want. Also from the previous link, it seems that workaround forces x86 devices to load x86 libraries, which we don't want. We want the ARM libraries to get loaded through Houdini.

So for now the only workaround I can think of for this issue is to include x86 in your abiFilters. If you want to reduce the binary size you should go with split APKs. It would be nice if someone could crack that "Unsupported feature" error message as it would be nice to not have to switch to split APKs just to use React Native (as the binary size increase without split APKs is prohibitive).

[lyahdav]

I did a bit more digging. I think my suspicion from the previous comment is correct. I tried modifying the base React Native Android project to just run these lines in the MainActivity and remove all mention of ReactActivity:

SoLoader.init(this.getApplication(), false);
SoLoader.loadLibrary("reactnativejnifb");

I get the same Houdini error as before:

10-22 20:59:46.803 6048-6048/? D/houdini: [6048] Loading library(version: 4.0.8.45720 RELEASE)... successfully.
10-22 20:59:46.803 6048-6048/? D/houdini: [6048] Unsupported feature (ID:0x10600cae).
10-22 20:59:46.803 6048-6048/? D/houdini: [6048] Open Native Library /data/app-lib/com.emptyrnproject-2/libreactnativejnifb.so failed.
10-22 21:06:25.713 8042-8042/? E/dalvikvm: dlopen("/data/app-lib/com.emptyrnproject-2/libreactnativejnifb.so") failed: dlopen failed: "/data/app-lib/com.emptyrnproject-2/libreactnativejnifb.so" has unexpected e_machine: 40
com.facebook.soloader.SoLoader$WrongAbiError: APK was built for a different platform

But, when I change it to SoLoader.loadLibrary("gnustl_shared"); it doesn't crash anymore. It crashes for all of the .so files included with React Native except for gnustl_shared. So I suspect there is something that's being used in those other .so files that Houdini doesn't like. I'm assuming those .so files are generated by files such as this one?

[yanbober]

@lyahdav I have the same issues, have you fixed it?

[lyahdav]

@yanbober No I haven't had time to further investigate yet.

[yanbober]

@lyahdav I think this is a very big bug for RN Android. level as RN not support armeabi so.

[lyahdav]

I don't entirely understand what you are saying but RN does support arm and
x86, it just doesn't support Houdini to translate from arm to x68. You can
work around this as I explained in the comments above.

On Sun, Dec 18, 2016 at 8:00 PM yanbo [e-mail] wrote:

@lyahdav https://github.com/lyahdav I think this is a very big bug for
RN Android. level as RN not support armeabi so.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/5773#issuecomment-267877202,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAV69Y2e14WbXrsteOC2EvoAlj74DqKKks5rJgFjgaJpZM4HUDGq
.

[yanbober]

OK, 3Q.

[hey99xx]

In case we would like to run react-native conditionally , so we can at least avoid crashing on these devices , is there a standard way to check whether the underlying architecture would support React or not?

[hramos]

Let's discuss this in the related issue that is still open.

[hramos]

Duplicate of #12246

[qiyue5755]

I also have this problem with 0.51.0？Is there a solution to this problem?

[qiyue5755]

@hramos I am sorry, I also have this problem with 0.51.0? Is there a solution to this problem?

[lyahdav]

There is no known solution, but there are workarounds such as including the x86 binaries with your app. If you're worried about binary size then use split APK.