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.

[kmagiera]

@ide feel free to send PR, I'll update here once we start working on this but I don't expect this to happen within the next couple of weeks.

[LegNeato]

FWIW Facebook does ABI apk splitting (and others). Whenever we ship we ship ~14 apks to the store. Out of that 14 we had a fallback that supported everything (no splitting) but virtually no device ever installed it because the others were sufficient.

[Matthew-C]

Hi,
any plan to solve this issue in the near future? It simply blocks us using react-native on Nexus 9.

[ide]

@Matthew-C I haven't heard any updates. If you need this feature, please help out!

[mkonicek]

@Matthew-C This workaround might unblock you (see the discussion above): https://corbt.com/posts/2015/09/18/mixing-32-and-64bit-dependencies-in-android.html

[atticoos]

+1 on this, our product has some 64bit dependencies as well

[lklots]

@corbt thank you for publishing the workaround, works fine! https://corbt.com/posts/2015/09/18/mixing-32-and-64bit-dependencies-in-android.html

[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/android-react-native-for-android-is-incompatible-with-3rd-party-64-bit-libraries

ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.

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

[afilp]

Isn't react-native 0.60 solving the problem?

[joshfriend]

@afilp check the release notes: https://github.com/facebook/react-native/releases/tag/v0.59.0

[jgreen210]

The latest release is currently 0.59.2. There is not yet a 0.60.

[afilp]

Indeed, I meant to say "0.59 solving the problem", sorry for the confusion.

[ggsrivas]

Does this means that all the react native apps will have to upgrade their RN version to 0.0.59 or higher for pushing any update to play store starting August 1st, 2019?

[AdamZaczek]

I'm getting the following warning:
This release is not compliant with the Google Play 64-bit requirement.
I'm very confused, react native 0.59 is supposed to support 64-bit. Do you know why did I get this message?

[awidiyadew]

@AdamZaczek after upgrade to RN 0.59 try to add x64 build config on /android/app/build.gradle following android official docs.
https://developer.android.com/distribute/best-practices/develop/64-bit

// Your app's build.gradle
apply plugin: 'com.android.app'

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

To make sure there's no missing library try to decompress apk, and open libs, U will find directory arm64-v8a and x86_64. Make sure that total files in 32 bit (x86 and armeabi-v7a) and x64 bit are same.

[antoinerousseau]

You can use this tool to know what changed in the project files that are not dependencies thus not automatically updated when updating RN, e.g.:
https://github.com/react-native-community/rn-diff-purge/compare/release/0.58.6..release/0.59.5#diff-b5a6cecd7ee362715d6306d583e73612

[prrenish]

 defaultConfig {

ndk{
    abiFilters "armeabi-v7a","x86"
}
packagingOptions {
    exclude "lib/arm64-v8a/libimagepipeline.so"
}
}

this worked for me

[nunobasto]

I have several Apps with RN 0.54.2. Is there no way I can get a 64bit version without upgrading to 0.59?

I've tried a couple times to upgrade with rn-diff-purge or react-native upgrade but I spend a lot of time solving conflicts and in the end the project doesn't work correctly.

[saadsaleem187]

My react native version is 0.59 but my app is not working on android 9 after downloading from play store. I followed the @prrenish way but id didn't worked for me. Also i generated Android App Bundle of my app and uploaded to google play console but app still on working on android 9.

[Dror-Bar]

So what are the exact steps required after upgrading an app to RN 0.59 so that it will be both 32bit and 64 compliant? I've seen several different suggestions so far such as this, this and this.

[HarshitMadhav]

Anyone please update on the question of @Dror-Bar ? I also have the same question.

[Dror-Bar]

By the way, I needed to update from version 0.55.4 to 0.59.8.
As mentioned here by kelset, in order do that I need to use rn-diff-purge to manually change all the necessary files. This ended up being a very tedious process. At the end, I managed to get Android version to work, but on IOS I had a generic linker error that was hard to debug and I couldn't solve.

So, I finally decided to just initialise a new project with the latest version, then simply copy my src folder, make the necessary package updates from there, then run Android Studio and Xcode and see that it compiles successfully . Surprisingly, while I still had to update a few 3rd party packages, this ended up being a much cleaner and easier solution.

[jeniasaigak]

So what are the exact steps required after upgrading an app to RN 0.59 so that it will be both 32bit and 64 compliant? I've seen several different suggestions so far such as this, this and this.

Add line from this answer:

ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'

Alternatively it can be (the same):

ndk {
    abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
}

Then create your build using this command:

(cd android && ./gradlew bundleRelease)

It will create Android App Bundle file, located at:

android/app/build/outputs/bundle/release/app.aab

Upload app.aab file to the Play Market.

This steps solved my issue. Hope it will help someone.

[antoinerousseau]

I'd start with https://github.com/react-native-community/rn-diff-purge

[shoopi12]

@zmefz
Hey, I might have missed some documentation... I usually use a release APK file located at android/app/build/outputs/apk/release/app-release.apk.
What is the difference between release APK file and app.aab bundle exactly?

[Dror-Bar]

@shoopi12 it's covered here and here.

[iagormoraes]

@shoopi12 it's covered here and here.

Is this required, to generate an app ABB instead of APK for 1st august compliance.

[Dror-Bar]

@IagorM I think it has to do with React Native 0.59+ which supports 64 bit (you can see it supports arm64-v8a and x86_64 in addition to armeabi-v7a and x86 in android/app/build.gradle).

I believe ABB is only to reduce overall APK size by creating a bundle that Goole Play later chooses just the necessary libraries to install on the device.

[saadsaleem187]

I solved this issue by changing my Rest API URL from "http" to "https". If your API URL type is "http" it will not work on android 9. By changing to "https" my app is working fine now.

[pencilcheck]

This article seems to work for me, esp the part about "Better solution"
https://badoo.com/techblog/blog/2017/06/30/integration-react-native-in-an-existing-application/