React-native: 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:

• [x] 64-bit JSC: https://github.com/facebook/android-jsc/issues/5
• [ ] Targeting armv8 with Buck: https://github.com/facebook/buck/issues/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

[ajwhite]

+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.

[MattFoley]

@ide and @mkonicek, I think we should consider re-opening this. Am I understanding correctly that the underlying issue is that JavaScriptCore hasn't been compiled to 64bit for Android?

Is the Android architecture landscape wildly different from the iOS architecture landscape? On iOS, you've been required to support arm64 over a year. If Google takes on this stance, than this is no longer a product pain, and becomes a massive blocker for many developers using React Native.

I argue that due to this, as well as the large performance gain 64bit architectures have over 32bit, this should be reopened and prioritized. If you can provide direction on what needs to be done, it's possible that we can devote time to helping with this effort, as this will quickly become a blocker for us here at Skillz (game developers need all the performance they can get).

Thanks!

[csotiriou]

This is indeed a blocker for us, too. We are really interested into using react native in our company, but the lack of 64-bit architectures on android is a real show-stopper, since we definitely need to use some C++ dependencies as well (we build some augmented reality apps)

Throwing away all 64 bit libs as indicated in this post ( https://corbt.com/posts/2015/09/18/mixing-32-and-64bit-dependencies-in-android.html ) is not an actual workaround, it's a hack, that can only get you this far.

Can we at least have an indication regarding this issue's progress (if any)?

[MattFoley]

@csotiriou from what I can tell, the best description of the work needed done is expanded upon here by @ide. Item number three seems to be a pretty big rabbit hole at the moment, with no real clear definition. The first two items however are accurate. Item one seems to be a sizable chunk of work, and less defined, whereas item two seems to be smaller and has what seems to be a clear path forward laid out by this issue on Buck.

[ide]

A good starting point would be to address all the checkboxes in my post above. Get all dependencies working with 64-bit, and add support for armv8 to Buck. Once that's done, it makes more sense to revive the conversation about getting RN compiling for 64-bit.

[LegNeato]

FWIW I added an untested patch to https://github.com/facebook/buck/issues/414

[felipecsl]

We found a slightly better workaround for this issue than the one mentioned by @kmagiera, based on this blog post
We're doing something like this:

ext.nativeLibsExcludeList = Arrays.asList('libFoo.so', 'libBar.so', ...)
packagingOptions { 
  exclude {
    // ... other excluded files
    for (String excludedLib : nativeLibsExcludeList) {
        exclude "lib/mips64/$excludedLib"
        exclude "lib/arm64-v8a/$excludedLib"
        exclude "lib/x86_64/$excludedLib"
    }
  }
}

nativeLibsExcludeList has to include all the native libraries included in your 64bit platform directories. You can find that out by opening your APK and looking into which files are there.
This is better than the abiFilters because that one may prevent you from publishing your app update if you have previou(s) APK(s) that include explicit support for one or more of the 64bit native platforms. If that happens, Google Play Dashboard won't let you publish the update with an error because you can't downgrade the existing apps or something similar.
With this exclude solution, you're technically still supporting all the possible native platforms and Android will automatically serve the 32bit libraries for 64bit devices for you.

[lorrainefox]

We are well into an important mobile app that is ReactNative for Android/iOS and can resort to the removal of the 64 bit libs, but a solution is very important to us. Adding this comment to up vote work on the solution.

[leeight]

+1

[LegNeato]

• [x] 64-bit JSC: facebook/android-jsc#5 -- @leeight has a PR up 🎉
• [x] Targeting armv8 with Buck: facebook/buck#414 -- I fixed this in Buck master 🍻
• [ ] Building all the dependencies with 64-bit support -- No one working on it 😢

There should be enough working here with @leeight's outstanding PR and my landed Buck change to start working on the react-native 64bit dependencies. Any takers?

[artdent]

Here's a slightly more robust variant of the packagingOptions workaround mentioned above:

    packagingOptions {
        exclude '/lib/mips64/**'
        exclude '/lib/arm64-v8a/**'
        exclude '/lib/x86_64/**'
    }

This excludes all 64-bit libraries from the apk, without requiring you to enumerate them specifically.

Now, is this better than the other workaround of specifically targeting just the armeabi-v7a and x86 architectures in the ndk block? I don't know. I do know that the device targeting workaround caused the Play Store to tell me that my app would target 40 fewer device models, out of about 9500. But I couldn't figure out how to get the list of what those devices are, so I don't know if any are actually used in the real world.

[antoinerousseau]

I implemented @artdent's solution but I still get this from a Nexus 5...

java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libreactnativejni.so

[wqqgt]

I have the same problem !

[aem]

@corbt's solution worked to get our app running, but ideally we'd like to be running in 64-bit mode. Is getting the binaries built to target 64-bit at all on Facebook's radar?

[lorrainefox]

I have the same request, that we can run in 64-bit mode.

On Wed, Feb 8, 2017 at 10:04 AM, Adam Markon [e-mail]
wrote:

@corbt https://github.com/corbt's solution worked to get our app
running, but ideally we'd like to be running in 64-bit mode. Is getting the
binaries built to target 64-bit at all on Facebook's radar?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/2814#issuecomment-278411247,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABHA4TKlVS6-Fwy_qGGFHJ17fuAaK7peks5ragOUgaJpZM4F_XHG
.

[denisk20]

I have tried the workarounds above, one which excludes 64bit binaries and another which targets armeabi-v7a and x86 architectures, and in both cases I'm getting the same error when trying on x86_64 emulator (API 25):

com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError: expected dynamic type `int64', but had type `null'
  at com.facebook.react.bridge.ReadableNativeMap.getInt(Native Method)
  at com.facebook.react.devsupport.StackTraceHelper.convertJsStackTrace(StackTraceHelper.java:103)
  at com.facebook.react.devsupport.DevSupportManagerImpl$3.run(DevSupportManagerImpl.java:287)
  at android.os.Handler.handleCallback(Handler.java:751)
  at android.os.Handler.dispatchMessage(Handler.java:95)
  at android.os.Looper.loop(Looper.java:154)
  at android.app.ActivityThread.main(ActivityThread.java:6119)
  at java.lang.reflect.Method.invoke(Native Method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

What might be causing it?

[petterh]

@denisk20: Your UnexpectedNativeTypeException is almost certainly caused by a missing lineNumber in a JS stack trace. I created a PR to fix it – I gather my fix didn't make it into 0.43, but it is in the master branch, so might be included in the next release. (?)

EDIT

There's an issue for this, though it's not related to the 32/64-bit issue, I think.

[anudeepreddygopu]

Hey, can anyone help with the question I have posted here
http://stackoverflow.com/questions/43368926/android-native-script-java-lang-unsatisfiedlinkerrorcould-find-dso-to-load-lib

[csotiriou]

@LegNeato @leeight regarding the pull request for jxcore https://github.com/facebook/android-jsc/pull/19

Think that if this gets merged, and react native will depend on it for 64 bit support, RN will be forced to drop support for devices it currently supports. Something that needs to be heavily considered. I for one like to look fordward, so I believe that support for Android 4.1 is not needed anymore.

Regarding this issue, if this pull request works then I believe we need to proceed with fixing this issue after it gets merged, as the inability to use 64 bit libraries is slowly killing adoption of RN. It is also something that kills projects as it is not mentioned beforehand in the main documentation, and many projects start without knowing this.

[LegNeato]

I don't think merginf will drop support for any phones...worst-case you can still only build the 32bit flavor of this lib. Also, the API version bump is just for building this, not for running AFAIK.

I could be wrong though, been a while since I looked at the specifics.

[vipcxj]

new jsc this project seems provide a improved jsc which support 64bit device. I haven't try it.

[julee]

We tested, if a machine support arm64-v8a, compared to armeabi-v7a, arm64-v8a has more performance advantages. Especially if we need CPU to do multimedia processing (e.g decoding, encoding), some VR operation based on CPU calculation, the performance of arm64-v8a is twice than armeabi-v7a.

If an app wants to use or develop the related functions described above, React Native is completely unavailable because Reactive Native does not support arm64. Since an app entire process can only run under an abi, this not available means that the entire app is completely can't use React Native, not only a component.

It is difficult to imagine almost all new phones are arm64 today, Android app can only run on the 32-bit architecture.
In contrast, on the iPhone, Apple has even no longer support 32-bit app.

Bye, Native React,
Bye, All These Outdated technology.

[teaserbot]

@julee so what you using now? much better stuff, me thinks :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

[simonracz]

Do not close. This issue is important.

[trevorah]

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

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.

[vipcxj]

The dead line is coming~

[SandroMachado]

I raised this concern on reddit and @grabbou or someone with his nickname :) replied.

I wouldn't worry too much about the fact that there was no update or clarification yet.

Facebook and many other companies, including Microsoft and their Skype app, are extensively using React Native in production. Their employees are already contributing heavily to the repository on regular basis, working on whatever is on their internal roadmap for the framework.

The support will land, it's just a matter of time. I will highlight this concern at the closest meeting and get attention from Facebook.

So, I think that this will not be a problem in the near future.

[grabbou]

Yeah, it was me xd

Just to clarify, by saying "will land", I expressed my belief (which seems to be pretty reasonable as I can't imagine major app being taken down because of this).

[jcampbell05]

Will be big help if this could land soon. It would be nice if this could form some kind of roadmap as currently React Native seems to lack one.

[ide]

There is nothing to land soon (there are no PRs or work in progress). There is the August 2019 deadline and enough apps rely on RN that I'm relatively confident 64-bit support will be ready by then (~18 months out).

[nhducit]

My company remove the RN integration in mobile app because this issue :(.

[rajsuvariya]

@nhducit Your company looks smart :D.

[gengjiawen]

First we need to merge this pr https://github.com/facebook/android-jsc/pull/19. Also fix android build failure in master branch.

@grabbou Can you do something to get this pr merged ?

[hovox]

Are there any Facebook engineers currently working on this issue? If Facebook uses React Native in the main Facebook app, then I don't believe that main app lacks 64 bit support.

[SandroMachado]

@hovox check this and this.

[hovox]

@grabbou Did you get any info from Facebook devs about this issue?

[gengjiawen]

Actually add this support won't be much hard, community has do lots of work. But it's hard to find the right one to push this. Only get https://github.com/facebook/android-jsc/pull/19 merged or similar pr merged will we have some real progress.

[CoreFloDev]

@gengjiawen I think the issue with this PR is that it will force react native to be min sdk 21. It will imply that react native will not be usable for 17% more of the market device according to https://developer.android.com/about/dashboards/index.html

[gengjiawen]

Looks like that pr need to be improved. But still, we need to get someone in fb who have merge write right to that repo.

[gengjiawen]

I add another pr which fix broken link and add ci support. As for min sdk, I think we can still use min sdk 16 because it use 21 to build because arm64 was added in 21.
After 171min builds, the unpacked aar like this

├── AndroidManifest.xml
├── R.txt
├── assets
│   └── lib
├── classes.jar
├── jni
│   ├── arm64-v8a
│   │   ├── libgnustl_shared.so
│   │   ├── libicu_common.so
│   │   └── libjsc.so
│   ├── armeabi-v7a
│   │   ├── libgnustl_shared.so
│   │   ├── libicu_common.so
│   │   └── libjsc.so
│   ├── x86
│   │   ├── libgnustl_shared.so
│   │   ├── libicu_common.so
│   │   └── libjsc.so
│   └── x86_64
│       ├── libgnustl_shared.so
│       ├── libicu_common.so
│       └── libjsc.so
└── res

[gengjiawen]

I have finished the pr https://github.com/facebook/react-native/pull/18754. If facebook okay with binary aar android-jsc, then the pr can be directly merged. Otherwise merge https://github.com/facebook/android-jsc/pull/30 first.

[gengjiawen]

For anyone want to help test, you can download RNTester for different apk here: https://github.com/gengjiawen/react-native/releases/tag/v0.56beta. I have test on x86 on android-emulator 19 and arm64 on real device android 21.

[gengjiawen]

@grabbou @janicduplessis Do you have write access to android-jsc so my pr can be reviewed ?

[grabbou]

I don't, but I guess @ide might have?

On Wed, Apr 11, 2018, 2:40 AM Jiawen Geng [e-mail] wrote:

@grabbou https://github.com/grabbou @janicduplessis
https://github.com/janicduplessis Do you have write access to
android-jsc so my pr can be reviewed ?

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

[gengjiawen]

As far as I known, he doesn't have.

[vipcxj]

It seems that fb group don't care this issue. For three years, there is no fb member comment here ever.

[jcampbell05]

it looks like there is progress

[csotiriou]

From the community, sure. Sad that no big company has invested time into this.

[gengjiawen]

Looks like hard to find someone to review my pr :(

[jcampbell05]

@alloy do you know anyone who could from Artsy?

[govi]

@gengjiawen We are testing a variant we built by customizing the build scripts. But, we are seeing set faults on Samsung S7. Have you ever tried it on that device before?

[gengjiawen]

Nope, what error do you get ? Have tried RNTester https://github.com/gengjiawen/react-native/releases/tag/v0.56beta.

[hwangjr]

any progress about this? in fact, this is really important.

[gengjiawen]

@grabbou The pr I created can directly merged if we not update android-jsc repo, can you take time to review my pr ?

[hramos]

FWIW, I don't have write access to the android-jsc repo either. What's keeping you from using the SoftwareMansion variant?

[gengjiawen]

SoftwareMansion variant has arm64 suppport. But it's not official and fully tested (jsc version is not the same with facebook android-jsc). Whether or not my pr got merged, I wish we can fix the issue soon. Delay this thing around google's deadline (August 2019) is too risky.

[LegNeato]

I did a PR that I hope will help unblock this on the buck side:

https://github.com/facebook/buck/pull/1889

It will allow NDK's app_platform to vary by CPU ABI. React Native's android-jsc will then need something like:

[ndk]
  app_platform = android-16
  app_platform-arm64 = android-21

[SergiuTaranu]

https://github.com/SoftwareMansion/jsc-android-buildscripts

[gengjiawen]

@sebmarkbage Sir, can you do something to push this ? Review community pr or do it inside facebook.

[hramos]

SoftwareMansion's JSC repo is legit, and is an effort that sprung from several core React Native contributors.

[gengjiawen]

@hramos If you prefer SoftwareMansion's JSC, then maybe add this to this repo. I think arm64 support should be official, not the thing need developers to manually config.

[hramos]

@gengjiawen we're not using that JSC at Facebook. Priority for now is to maintain consistency with what Facebook uses, at least within this repo.

[gengjiawen]

@hramos Does facebook switch to v8 to execute js ? Will it come to react native ?

[AugustoAleGon]

Any progress of this? It has been almost 3 years :0

[esilverberg]

Airbnb cites this issue specifically as one of the reasons they dropped React Native.

https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838

[gengjiawen]

For the update, you can see https://github.com/facebook/react-native/issues/19737.

[gengjiawen]

I am thinking make a showcase for how enable 64 support for 0.56.0, any thought ?

[gengjiawen]

After this issue fixed https://github.com/facebook/metro/issues/181, I may have time work an example.

[gengjiawen]

I want to give you the show case, but I have stuck by the issue https://github.com/facebook/react-native/issues/20353. So let's wait the official team fix the issue.

[gengjiawen]

I have finish my demo how to support 64bit cpu, you can check here https://github.com/gengjiawen/ReactNative64bitDemo. The demo is based on my pr: https://github.com/facebook/react-native/pull/18754.

[luisnaranjo733]

@gengjiawen I'm curious - do you know how much your app size increased by supporting 64 bit?

[hramos]

This was closed automatically once 0a2825f8b3dc183bb17c9aa18d778ddb0f641a66 landed, but I'm going to re-open since we're not quite done here yet.

[hramos]

@gengjiawen now that 0a2825f has landed on master, what's next on our task list? I'm prioritizing 64-bit library support, just let me know what we can do on our end to solve this.

[gengjiawen]

Here are my thoughts:

• Release a new version to make this available to community.
• Find a better way to to handle the aar binary file instead of put it directly in this repo.
• Maybe add abi split in docs.

[hb2708]

When this will be available for public to use?

[hramos]

One of the main blockers, a 64-bit JSC, was just resolved in https://github.com/facebook/react-native/commit/f3e5cce4745c0ad9a5c697be772757a03e15edc5.

[ericksprengel]

Important note published yesterday on Android Developers Blog:

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.

Starting August 1, 2019

https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html

[grange74]

@ericksprengel thanks for sharing. It would be good to add the following to your quote so that people don't panic between seeing your post and reading the referenced link.

Starting August 1, 2019

[hramos]

@grange74 I edited the original post in this issue to include the full timeline from the article.

[csotiriou]

Now that 0.58 is released, does it solve this issue? Is react native 64-bit yet?

[hramos]

It should be solved, to my understanding. Did you run into any issues when using 0.58?

[hramos]

Apologies, this is not in 0.58. It's in master, though, and is scheduled to be part of the 0.59 release.

[hugopretorius914]

Hey there, I am on 58.3 and got the issue below

After adding the following to my 'build.gradle' it works just fine

Hope this can help you all

[hramos]

I think this can be closed, given it's in master already.

[afilp]

@hramos Since all our builds fail when using the Android Bundle logic in Google Play Console, could the fix that is included in minor 0.58.4 be released on npm please?

Thanks a lot!

[hramos]

@afilp you can request minor fixes to be cherry picked into an existing stable release here: https://github.com/react-native-community/react-native-releases/issues/81

[gedeagas]

if anyone need to copy @hugopretorius72 answer

packagingOptions { pickFirst 'lib/x86_64/libjsc.so' pickFirst 'lib/arm64-v8a/libjsc.so' }

Notes: Only for lazy people hahaha 😉

[zjx]

@gedeagas this is really helpful 😈

[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.

[zmefz]

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/