Road to v0.65.0 - RC2 phase

[kelset]

This issue serves to track the status of work to reach 0.65.0.

Current latest: 0.65.0-rc.2
Changelog draft PR: #234

Known issues

• iOS: Some reports of Folly dual symbols preventing ios from building successfully. Investigation is ongoing.

Commits (and PRs) to cherry pick

• Bump flipper deps to from 0.91 to 0.93 (ios) - facebook/react-native@848d599
• Android: upgrading to OkHttp from 4.9.0 to 4.9.1 to fix java.lang.NullPointerException: bio == null crash facebook/react-native@6caec9d
• Fix support for blobs larger than 64 KB on Android facebook/react-native@f00e348
• fix: update to @jest/create-cache-key-function@27 facebook/react-native@2f477b1
• (not sure) bump local files (yarn.lock/podfile) to Hermes 0.8.1 https://github.com/facebook/hermes/releases/tag/v0.8.1
• bump to Metro (via lockfile)

Non-blocking for RC release

• Hermes Support for ARM64 simulator & Catalyst: merged as facebook/hermes@62e5abe - needs a Hermes release?
• Allow PlatformColor to work with RCTView border colors facebook/react-native@c974cbf
• Accessible colors for DynamicColorIOS facebook/react-native@4b9d9dd

Local commits to backport to main

• facebook/react-native@cae0637
• facebook/react-native@f6accd2 (need to check if this is actually needed in main)
• facebook/react-native@5aae7fc

---

Please limit your comments to reports of issues encountered with the RC and cherry pick suggestions. No ETA currently for when 0.65.0 will be released.

[a-eid]

RC0:

• as mentioned above android does crash on startup.
• iOS is building correctly for me on M1 ( using xcode 12.4 & n node version manager ).

[janicduplessis]

Could the android crash be facebook/hermes#513?

[Titozzz]

@janicduplessis No it happens on non hermes builds too

[kelset]

@a-eid thanks for reporting - I guess you tested npx react-native init generated projects?

@janicduplessis as pointed out by @Titozzz this happens even in non-hermes builds too, it seems to be caused by some lib.so not getting created/generated so when the App tries to open it looks for them and goes kaboom instead. That said, it could very well be that once we fix this one, the issue you are linking might happen so thanks for surfacing it 😅

[a-eid]

@kelset yes that's correct, shortly after it was released.

android studio logs

2021-06-09 17:17:46.426 4659-4686/? E/SoLoader: couldn't find DSO to load: libfbjni.so
    	SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/com.rn065/lib-main flags = 1]
    	SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/~~hDUiJasd5BMTagPArbh6aQ==/com.rn065-rJuDeCMgpLIn0bRJrxunkA==/lib/arm64 flags = 0]
    	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
    	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
    	Native lib dir: /data/app/~~hDUiJasd5BMTagPArbh6aQ==/com.rn065-rJuDeCMgpLIn0bRJrxunkA==/lib/arm64
     result: 0
    
    --------- beginning of crash
2021-06-09 17:17:46.426 4659-4686/? E/AndroidRuntime: FATAL EXCEPTION: FlipperConnectionThread
    Process: com.rn065, PID: 4659
    java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libfbjni.so
    	SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/com.rn065/lib-main flags = 1]
    	SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/~~hDUiJasd5BMTagPArbh6aQ==/com.rn065-rJuDeCMgpLIn0bRJrxunkA==/lib/arm64 flags = 0]
    	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
    	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
    	Native lib dir: /data/app/~~hDUiJasd5BMTagPArbh6aQ==/com.rn065-rJuDeCMgpLIn0bRJrxunkA==/lib/arm64
     result: 0
        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:918)
        at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:740)
        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:654)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:634)
        at com.facebook.soloader.NativeLoaderToSoLoaderDelegate.loadLibrary(NativeLoaderToSoLoaderDelegate.java:29)
        at com.facebook.soloader.nativeloader.NativeLoader.loadLibrary(NativeLoader.java:51)
        at com.facebook.soloader.nativeloader.NativeLoader.loadLibrary(NativeLoader.java:30)
        at com.facebook.jni.HybridData.<clinit>(HybridData.java:34)
        at com.facebook.flipper.android.FlipperThread.run(FlipperThread.java:25)

seems to be related to flipper, but I'm not sure.

[kelset]

My hope is that it will be fixed by facebook/react-native#31675 but until it's merged and tested we can't be sure

[robertying]

Could this PR facebook/react-native#31062 get looked at and merged? It was in v0.64.2 need-to-merge list but has not been looked at by a maintainer. It unblocks build for Mac Catalyst.

[robertying]

facebook/react-native@b496a53 Catalyst PR was merged! Hopefully the commit can go into this release. With the incoming Hermes's build for Mac Catalyst, Catalyst will become very much usable now.

[kelset]

Update on the Android crash problem. Basically, this is rooted in the fact that some build steps for Android during CI don't fail properly so the script thinks that all the artifacts are being generated, and proceeds. With the result that the "react native library" is missing said files -> a generated Android apk crashes on startup because of those files not being there.

Currently, we are not sure of why this happens, but if the script to generate those files gets run twice on the 2nd pass it seems to always generate them properly. Because of this "proven workaround", @Titozzz created this: https://github.com/facebook/react-native/pull/31707/files for the 0.65-stable branch.

That said, I've investigated this problem a bit deeper and here's what I found: the script not generating the artifacts is ./gradlew :ReactAndroid:installArchives.
This task was changed by this commit by @dulmandakh facebook/react-native@fc6fc63 to basically be a "backward compatibility" alias for the new way of generating artifacts/publishing dictated by Gradle (before it was a task defined in the ReactAndroid/release.gradle file that the commit removes).
In particular, it has become an alias for publishReleasePublicationToNpmRepository which is one of the available tasks for the new Maven Publish Plugin; in particular, it's publishPubNamePublicationToRepoNameRepository.

By reading that documentation, it seems that we could potentially replace all the places where we invoke ./gradlew :ReactAndroid:installArchives with ./gradlew :ReactAndroid:publish, and remove the alias in the ReactAndroid/build.gradle file. My current assumption is that because of that aliasing some errors are not being bubbled up correctly hence the (small) level of checks that we have in place for the command/artifact generation is not picking up the files not being generated.

Anecdotally, I tried to run ./gradlew :ReactAndroid:publish once locally to see if it worked, and it seems to have created all the necessary artifacts on first pass. More testing would help verify if that's the case.

[Titozzz]

The culprit is facebook/react-native@7599593

What I've noticed before: if you run ./gradlew clean it ends up building many things after:

> Configure project :react-native-gradle-plugin
> Task :react-native-gradle-plugin:compileKotlin
> Task :ReactAndroid:cleanReactNdkLib
(everything below doesn't happend after the update)
> Task :ReactAndroid:downloadBoost
> Task :packages:react-native-codegen:android:buildCodegenCLI
> Task :packages:rn-tester:android:app:generateCodegenSchemaFromJavaScript
> Task :packages:rn-tester:android:app:generateCodegenArtifactsFromSchema
> Task :ReactAndroid:generateCodegenSchemaFromJavaScript
> Task :ReactAndroid:generateCodegenArtifactsFromSchema
> Task :ReactAndroid:downloadDoubleConversion
> Task :ReactAndroid:downloadFolly
> Task :ReactAndroid:downloadGlog
> Task :ReactAndroid:buildReactNdkLib

So when running ./gradlew installArchives it doesn't even re-do the ReactAndroid:buildReactNdkLib step and jni is correctly included

However after the update ./gradlew clean only cleans and doesn't rebuild everything so when we run ./gradlew installArchives it runs ReactAndroid:buildReactNdkLib but sadly doesn't include jni (on the first run, running it twice fixes it as we saw)

My guess is that :ReactAndroid:buildReactNdkLib or something else need to run before installArchives and before it happened as a side effect (during clean but maybe some other times too) and new gradle broke it.

EDIT: FYI we will revert the PR for now