Skip to content

Build 64bit binaries for Android - #19536

Closed
marafat wants to merge 22 commits into
react:masterfrom
plexinc:muhammad/arch-64-fb-submit-master
Closed

Build 64bit binaries for Android#19536
marafat wants to merge 22 commits into
react:masterfrom
plexinc:muhammad/arch-64-fb-submit-master

Conversation

@marafat

@marafatmarafat commented Jun 1, 2018

Copy link
Copy Markdown

Motivation

Add 64bit support to Android. Fixes#2814

How is this different from the previous effort done in #17640 and #18754

  1. This PR uses the JSC from the SoftwareMansion's forkmentioned under Support third-party 64-bit libraries on Android #2814
  2. It builds with NDK 16/clang
  3. it updates the APP_STL to c++_shared

Test Plan

  1. Make the RNTester app build a separate APK per abi
  2. assemble debug and release APK
$ cd react-native
react-native$ rm -rf ./node_modules && yarn install
react-native$ ./gradlew :ReactAndroid:cleanReactNdkLib :RNTester:android:app:clean :RNTester:android:app:assembleRelease

I found these to be beneficial against some build errors:

$ cd react-native
react-native$ rm -rf ./.buckd/
react-native$ rm -rf ./buck-out/
  1. use adb install to install the arm64-v8a APK on a PIXEL 2XL
$ cd react-native
react-native$ adb install ./RNTester/android/app/build/outputs/apk/app-arm64-v8a-release.apk
  1. the app runs fine in both cases.

Related PRs

[X] Todo: change instructions on building from source.react/react-native-website#394

Release Notes

[ANDROID] [ENHANCEMENT] [ReactAndroid] - add x86_64 arm64-v8a support.

@marafat
marafat requested a review from hramos as a code ownerJune 1, 2018 21:23
@facebook-github-botfacebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jun 1, 2018
@react-native-botreact-native-bot added ✅Test Plan Platform: Android Android applications. Type: Enhancement A new feature or enhancement of an existing feature. labels Jun 1, 2018
@hramos

Copy link
Copy Markdown
Contributor

Sweet. Let's make sure test_android is passing before merging. At this time, the test_android failure is unrelated to your change as master is failing with the same reason (#19309).

* master:
Bump metro@0.38.1
Remove duplicated attachWebsocketServer module
Switch to ES6 Class
Slider to ES6 Class
Slider move prop comments to flow types
Slider remove $FlowFixMe #take2
Revert D8234803: [RN] Slider remove $FlowFixMe
normalizeColor to compute regexps lazily
Implement release of FabricUIManager resources
Add backward compatible support for onLayout event in Fabric
refactor JSI module initialization
Slider remove $FlowFixMe
better place for dismiss all button
Low the priority for logging events in fabric
react-native-xcode.sh: Support Homebrew-installed nodenv
make logMarker visible for consistency with logTaggedMarker
@hey99xx

Copy link
Copy Markdown

@hramos in your other comment in #2814 (comment) you said you prefer to stick with existing JSC that FB uses. So are you ok with this PR integrating with the new JSC from SoftwareMansion? Aren't those conflicting statements, or did something happen to convince FB that new JSC is finally usable/stable?

* master:
skip dismiss all if all rows are hidden (react#19564)
Trigger nested VirtualizedLists to re-measure if their containing cell's onLayout fires
@Minishlink

Copy link
Copy Markdown
Contributor

@marafat Very nice!
test_android is now passing on master, can you rebase your branch please?

* master:
Fix NullPointerException when emiting event using UIManagerModule
Fixed concurrency issue in remote debugger
Fix ReactImagePropertyTest SoLoader failures (react#19607)
Remove unused include. (react#19548)
Update Danger token (react#19606)
Modified deepFreezeAndThrowOnMutationInDev to use Object.prototype.ha… (react#19598)
Change error message on interpolation (react#19571)
Bump Prettier to 1.13.4 on xplat
Fix/security issues (react#19373)
Add open source Flow declaration for Metro module
Use correct library reference for libfishhook.a in RCTWebSocket (react#19579)
Enable proguard for Fabric in release builds
Fix events not working after closing and navigating back to Fabric screen in FB4A
@marafat

Copy link
Copy Markdown
Author

@hramos looking at the logs of test_android it seems that we need to increase the storage specified on the container running the emulator. Not sure if you agree, but if you do, can you point me where I should do it and maybe suggest a new value.

Also, not sure how to fix test_ios_e2e but I will look into it.

Thanks!

@bestander

Copy link
Copy Markdown
Contributor

Hey everyone, I am not actively involved with RN recently, working on a product that uses RN now.
I'll point to this PR in our internal group.
Just FYI those things are usually hard to merge, dependencies management is complicated

@marafat

marafat commented Jun 14, 2018

Copy link
Copy Markdown
Author

Thank you @bestander for chiming in and for the internal push. I understand your point, and I tried as much as I could to make this PR as slim as possible.

For my personal notes, I made a document that represents the timeline of issues I faced trying to get this done, and the solution I chose for each. If you think this would be helpful in speeding up the review process I will be happy to share.

@marafat

marafat commented Jun 14, 2018

Copy link
Copy Markdown
Author

Thanks @hey99xx for the detailed help. I will incorporate asap...

Quoting the message from the commit that changed jscBaseUrl from svn to github:

It would be more in line with other dependencies to depend only on github for thirdparty bridge dependencies.

Although I find the svn link easier to update in the future, I will respect the internal strategy and use the github mirror link.

@kmagiera

Copy link
Copy Markdown
Contributor

Thanks for working on this @marafat – we've been waiting for updated JSC on Android for way too long.

As @kelset mentioned in #19737 we discussed that in some other thread and I suggested we split this into a few intermediate steps. Splitting this work will make it easier to merge as there are going to be a fewer moving parts. Also if it turns out we need to back out some of the parts we can still benefit from others that are ok.

My suggestion was to proceed as follows:

  1. PR that upgrades build tools (NDK, stl lib), we can also upgrade less strategic libs like: double-conv, glog etc
  2. Upgrade JSC version – we are actively working on JSC buildscripts right now and trying different versions. We are not yet convinced that JSC builds are 100% stable as we have seen some random crashes we haven't manage to reproduce or fix. We need some more data points from people who use jsc-android-buildscripts in production if they have any reports on that (please report on the project's github if you have seen any). We expect to move forward with that really soon.
  3. Enable 64bit architecture. For that we also need to figure out strategy of how this should be communicated. This changes files in app template and to make sure people start using it we need to add detailed description to the release notes (this comes as a fragment of PR description). We should verify that this works fine with Android App Bundle feature of Google Play, otherwise even simple RN apps will be very large (like 40MB). We also should add a chapter to documentation explaining why debug builds are huge and that it is not what the users who install the app would get.

@gengjiawen

gengjiawen commented Jun 18, 2018

Copy link
Copy Markdown
Contributor

I think stay in one pr is okay, since the main motivation update current toolchain is getting arm64 support.

cd $NDK_HOME
echo "Downloading NDK..."
curl -o ndk.zip https://dl.google.com/android/repository/android-ndk-r10e-linux-x86_64.zip
curl -o ndk.zip https://dl.google.com/android/repository/android-ndk-r16-linux-x86_64.zip

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove android.useDeprecatedNdk=true in gradle.properties

This flag is not needed anymore the following reasons:
1. It is important when the gradle plugin is the one invoking the ndk
command.
2. For ReactAndroid, the ndk commnad (ndk-build in this case) is invoked
manually. See gradle task: buildReactNdkLib
3. If the gradle plugin is invoking the ndk command, these lines will
cause the plugin to invoke the ndkCompile (the deprecated ndk) over
ndk-build. This is undesired.
@bachvanthe1994

This comment has been minimized.

@gengjiawengengjiawen mentioned this pull request Jun 26, 2018
@facebook-github-bot

Copy link
Copy Markdown
Contributor

@marafat I tried to find reviewers for this pull request and wanted to ping them to take another look. However, based on the blame information for the files in this pull request I couldn't find any reviewers. This sometimes happens when the files in the pull request are new or don't exist on master anymore. Is this pull request still relevant? If yes could you please rebase? In case you know who has context on this code feel free to mention them in a comment (one person is fine). Thanks for reading and hope you will continue contributing to the project.

@bestander

Copy link
Copy Markdown
Contributor

A quick update, the teams inside FB know about the issue and are working on a solution to resolve it.
I don't have any ETA as the work is complicated but hopefully soon RN will be less coupled to a specific JSC.

@patrickkempff

Copy link
Copy Markdown
Contributor

@bestander thanks for the update. I am very curious, can you share a bit more information about this? 👍

@hramos

Copy link
Copy Markdown
Contributor

Lots of conflicts here, but they're likely due to the progress that has been made to update several of these dependencies in other PRs.

Like Konstantin said, we're working on making it easier to use a different JSC soon.

@hramoshramos added this to the 0.58 RC milestone Sep 25, 2018
@sospedra

Copy link
Copy Markdown

Hello dear mantainers <3
This is marked for the milestone 0.58
In order to organize ourselves, is this gonna happen finally? 😱 😍

@hey99xx

Copy link
Copy Markdown

@sospedra I think they're just taking this one #18754. So 64bit binary support will be there, but no update to the JSC engine (like this PR was doing) and will keep using the current android-jsc.

@hramos

Copy link
Copy Markdown
Contributor

Yes, it will happen, though I do not think it will definitely be in place for 0.58. There's some work we need to do to determine what actually needs to be done to support this, and it is being discussed at #2814. As @hey99xx and @bestander said, we need to do some work related to the JSC used in React Native on Android.

@hramos

Copy link
Copy Markdown
Contributor

The new JSC with 64-bit architectures is on master now. Any interest in resolving the conflicts here and moving the PR forward?

@hramoshramos removed this from the 0.58 RC milestone Jan 15, 2019
@hey99xx

Copy link
Copy Markdown

@hramos Practically everything that this PR was doing is already done by other PRs.

  • From f3e5cce "Use new JavaScriptCore from npm" commit message:

- Use clang instead of the deprecated gcc
- Use libc++ instead of the deprecated gnustl

  • 64-bit work was done earlier without the JSC upgrade in 0a2825f with a custom 64-bit build of the old android-jsc.aar checked in into the repo.

  • NDK bump from 10e to 17b was done in 6117a6c.

  • glog and double-conversion updates were done in b5fca80 and f32032e.

Maybe give @marafat chance to look again if there's still anything needed, but I'd think this PR can be closed without being merged in favor of all the other work completed.

@marafat

Copy link
Copy Markdown
Author

Closing - Thanks @hey99xx for providing links to all the pieces. I did go over all of them, and I confirm that they all collectively achieve everything this PR is trying to.

@hramos - for those getting here from google, I wonder if you can share a stable release number that will include 64bit support?

@marafatmarafat closed this Jan 18, 2019
@hramos

hramos commented Jan 19, 2019

Copy link
Copy Markdown
Contributor

The new JSC (the last piece of the puzzle) is scheduled for React Native 0.59.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA SignedThis label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.Platform: AndroidAndroid applications.Type: EnhancementA new feature or enhancement of an existing feature.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

12 participants

@marafat@hramos@hey99xx@Minishlink@gengjiawen@bestander@kmagiera@bachvanthe1994@facebook-github-bot@patrickkempff@sospedra@react-native-bot