Support third-party 64-bit libraries on Android

[corbt]

Excerpt from the Android Developers Blog article, Get your apps ready for the 64-bit requirement:
[added by @hramos]

The 64-bit requirement: what it means for developers

Starting August 1, 2019:

• All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play.
• Extension: Google Play will continue to accept 32-bit only updates to existing games that use Unity 5.6 or older until August 2021.

Starting August 1, 2021:

• Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices.
• This will include games built with Unity 5.6 or older.

The requirement does not apply to:

• APKs or app bundles explicitly targeting Wear OS or Android TV, which are form factors that do not currently support 64-bit code.
• APKs or app bundles that are not distributed to devices running Android 9 Pie or later.

Original Issue

Hey, it appears that React Native on Android doesn't provide a 64-bit version of the libreactnativejni.so native library, which can cause compatibility issues on 64-bit devices. I ran into this while attempting to integrate React Native with a large existing application I'm developing.

Steps to reproduce:

1. Create a new application with react-native init.
2. In the "android/app/build.gradle" file, add compile 'io.realm:realm-android:0.82.2' to the end of the dependencies {} block. (Note that I don't think this is an issue specifically caused by Realm, it's just an example dependency with a 64-bit native library).
3. Attempt to run on a Nexus 9.

Stack trace:

E/AndroidRuntime(32171): FATAL EXCEPTION: main
E/AndroidRuntime(32171): Process: com.androidemberall, PID: 32171
E/AndroidRuntime(32171): java.lang.UnsatisfiedLinkError: could find DSO to load: libreactnativejni.so
E/AndroidRuntime(32171):    at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:213)
E/AndroidRuntime(32171):    at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:178)
E/AndroidRuntime(32171):    at com.facebook.react.bridge.JSCJavaScriptExecutor.<clinit>(JSCJavaScriptExecutor.java:19)
...

I believe this to be caused by the shared library loading logic explained in this answer on StackOverflow. Since Realm includes a 64-bit native binary, the system no longer automatically falls back to the 32-bit version of libreactnativejni.so provided by React.

This bug is blocking me from integrating React Native into my existing application, which I'm really excited to try!

[mkonicek]

Thanks for reporting! Yes we don't provide 64-bit version of the native code and the system should always fall back to 32-bit. I believe @kmagiera has context on why we don't provide 64-bit version.

[corbt]

Like the stackoverflow answer says, the fallback doesn't work if there are other 64-bit native libraries. Most Android projects use a number of 3rd-party libraries, and any that include native 64-bit code will cause React Native to fail.

I think that Android's policy on this is strange (the way one library is loaded shouldn't affect another that doesn't depend on it), but as you can see if you follow my steps to reproduce, it does in fact fail. As more libraries switch to native 64-bit support and React Native gets used in more heterogeneous projects this will become more of an issue.

[kmagiera]

It definitely matters as all native libs share address space.

Workaround would be to follow build.grade from our examples and add the following block to defaultConfig:

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

see: https://github.com/facebook/react-native/blob/master/Examples/SampleApp/android/app/build.gradle

[corbt]

Yeah, I tested with that ndk block as well (it actually is included in the default project config generated by react-native init) and the issue still stands.

[corbt]

I've uploaded an example failing project here, in case it helps with debugging.

The only changes to the default React-Native-generated project are the addition of the README and the addition of the realm-android dependency.

[corbt]

Furthermore, I can confirm that installing the apk in 32-bit mode works on the nexus 9, as found in this SO answer (adb install --abi armeabi-v7a app-debug.apk)

[corbt]

I figured out a workaround in the short term (disabling all ARM64 binaries) and wrote it up in a blog. However, the right solution definitely needs to be proper ARM64 support, because that's the way the device ecosystem is moving).

If it isn't included because of concerns over binary size, maybe switching to the packaged V8 interpreter would help? Any ARM64 devices should come with it included, and perhaps falling back to the vendored JSC for devices where V8 isn't available could work.

[ide]

The fragmentation of running on different JS VMs is worth avoiding. It already kind of sucks that iOS 7/8/9 support different features, and the JS VM should be only a couple MB anyway.

Can ABI splits be used to address concerns about APK size? The idea is that you generate three APKs for 32bit, 64bit, simulator, and distribute them separately.

[corbt]

@ide yes, splits can be used to keep size down, although Google doesn't recommend it: "Although we encourage you to develop and publish a single APK that supports as many device configurations as possible, doing so is sometimes not possible" (emphasis theirs).

I think a reasonable solution would be to generate a monolithic APK by default with x86/arm/arm64 support, and allow individual developers to go through the hassle of producing multiple APKs if their app requires it. I don't think that just ignoring ARM64 will be a good long-term compromise -- it will become harder and harder to use 3rd-party libraries with React Native as more include ARM64 support and more 64-bit devices come to market.

[ide]

I kind of understand Google's solution though that's how Apple operated for almost a decade and they're moving to architecture-/device-specific binaries (but doing it all for you with their bitcode compiler).

allow individual developers to go through the hassle of producing multiple APKs if their app requires it

I like this solution as a starting point.

Things to track for 64-bit support are:

• 64-bit JSC: Support more android abis (arm64, x86_64) facebookarchive/android-jsc#5
• Targeting armv8 with Buck: arm64-v8a ABI is not supported in NdkCxxPlatform buck#414
• Building all the dependencies with 64-bit support (I tried this and some just don't work)

All of these are up-for-grabs. @kmagiera can you tell us if 64-bit is something that Facebook is actively interested in, or should people just start working on these items?

[kmagiera]

@ide I don't think we have anyone focusing on this at the moment. What are the specific things that doesn't compile for armv8? Except from JSC we build all the first-party and third-party libs RN depends on with BUCK for arm64 so it shouldn't take much to make android makefiles build them as well.

Speaking of split builds I don't think Google's recommendation apply in the case when 80% of the APK size comes from native libs. Don't have exact values with me at the moment but from what I remember JSC lib is around 2.3M for armv7 and 2.5M for x86 (uncompressed) which adds around 1.3M to the APK size. Considering the fact that arm64 are quite rare and all of them can run armv7 binaries (JSC with JIT enabled doesn't work with libhoudini if I recall correctly from our experiments, so I consider x86 android devices incapable of running armv7 in this case) I don't think we should default to armv7+arm64+x86 builds. My suggestion would be still to default to x86+armv7 but provide config for split builds for arm64 once it's supported

[ide]

@kmagiera - OK. So if people are interested in 64-bit support they should contribute.

I hit an issue with Google's double-conversion library but I could have specified the wrong compiler options. I didn't spend much time looking into it.