search

facebook / react-native

A framework for building native applications using React
https://reactnative.dev
MIT License
118.8k stars 24.29k forks source link

[HAS WORKAROUND] Android build fails since 0.71.0-rc.0 tag added #35204

Closed markholland closed 1 year ago

markholland commented 1 year ago

WORKAROUND

Issue #35210 now has the best description and current best-known fix for the issue

we are working hard to keep that issue up to date as we learn new things

go to the issue and get the workaround: #35210

Original issue report follows:

Description

Builds started failing couple hours ago.

* What went wrong:
Execution failed for task ':app:mergeReleaseNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.MergeNativeLibsTask$MergeNativeLibsTaskWorkAction
   > 2 files found with path 'lib/arm64-v8a/libfbjni.so' from inputs:
      - [redacted]/.gradle/caches/transforms-3/2952ab139faaa4b08a71276c5fc46221/transformed/jetified-react-native-0.71.0-rc.0-release/jni/arm64-v8a/libfbjni.so
      - [redacted]/.gradle/caches/transforms-3/d1c59095249a1169bea435013b70e0a9/transformed/jetified-fbjni-0.3.0/jni/arm64-v8a/libfbjni.so
     If you are using jniLibs and CMake IMPORTED targets, see
     https://developer.android.com/r/tools/jniLibs-vs-imported-targets

Version

0.68.3

Output of npx react-native info

info Fetching system and libraries information... System: OS: macOS 13.0 CPU: (20) arm64 Apple M1 Ultra Memory: 2.37 GB / 64.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.15.1 - ~/Library/Caches/fnm_multishells/89099_1667585876627/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 8.11.0 - ~/Library/Caches/fnm_multishells/89099_1667585876627/bin/npm Watchman: 2022.10.31.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: Not Found SDKs: iOS SDK: Platforms: DriverKit 22.1, iOS 16.1, macOS 13.0, tvOS 16.1, watchOS 9.1 Android SDK: Not Found IDEs: Android Studio: 2021.3 AI-213.7172.25.2113.9014738 Xcode: 14.1/14B47b - /usr/bin/xcodebuild Languages: Java: 11.0.16.1 - /usr/bin/javac npmPackages: @react-native-community/cli: Not Found react: 17.0.2 => 17.0.2 react-native: 0.68.3 => 0.68.3 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found

Steps to reproduce

Snack, code example, screenshot, or link to a repository

N/A

markholland commented 1 year ago

Here's an app I can share with the same issue but running React Native 0.69.6 https://github.com/catenda/pdftron-example-react-native

Edit: It's Friday evening where I am so I won't follow up until Monday but judging by the replies someone else should be able to help with any additional info needed.

afturner commented 1 year ago

We're seeing this as well. Apologies but I think it makes sense to ping the person that created the release (@cipolleschi)

bernygarza-bh commented 1 year ago

I am also seeing this error

leonardoquevedox commented 1 year ago

We're also seeing this error and is breaking all of our CI/CD pipelines

prolok commented 1 year ago

Same here, using 0.66.4 and getting the error only when 0.71.0-rc.0 is released.

Gabarros commented 1 year ago

Same here, breaking all of our builds since 0.71.0-rc.0 was released

saransh-malik commented 1 year ago

Same here, looks like all RN android builds are broken due to this

vladyslavNiemtsev commented 1 year ago

The same for me. For RN version 0.66.4

BlinkVonDoom commented 1 year ago

Same here, RN info below

System: OS: macOS 12.6 CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz Memory: 1.45 GB / 16.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.17.0 - /usr/local/bin/node Yarn: 1.22.19 - /usr/local/bin/yarn npm: 8.15.0 - /usr/local/bin/npm Watchman: Not Found Managers: CocoaPods: 1.11.3 - /Users/davidrankin/.rvm/gems/ruby-2.6.3/bin/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5 Android SDK: API Levels: 28, 29, 30, 31, 33 Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.2, 30.0.3, 31.0.0, 31.0.0 System Images: android-28 | Intel x86 Atom_64, android-30 | Google APIs Intel x86 Atom, android-31 | Intel x86 Atom_64, android-31 | Google APIs Intel x86 Atom_64, android-31 | Google Play Intel x86 Atom_64 Android NDK: Not Found IDEs: Android Studio: 2021.2 AI-212.5712.43.2112.8512546 Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild Languages: Java: 11.0.16.1 - /usr/local/Cellar/openjdk@11/11.0.16.1/libexec/openjdk.jdk/Contents/Home/bin/javac npmPackages: @react-native-community/cli: Not Found react: 17.0.2 => 17.0.2 react-native: 0.66.3 => 0.66.3 react-native-macos: Not Found npmGlobalPackages: react-native: Not Found

mikehardy commented 1 year ago

I posted this up in the releases-coordination channel of the react-native contributors discord as that is where a lot of the release work (or news about the work) is coordinated.

In the meantime, there may be some tricks to play with regard to excluding files, if someone has time to try:

https://stackoverflow.com/questions/29793992/exclude-native-library-in-gradle-android-build

Historically, react-native use to sometimes use a "pickFirst" directive, and that may be possible here, to force an election between the two similarly named .so files, this bears an experiment if someone affected has time (I do not, just trying to cross-pollinate here since this is undoubtedly a hot issue with many people interested / blocked right now)

https://github.com/facebook/react-native/blob/83425fa72f1f9a12f6b6deefd66fa8bd154a3651/template/android/app/build.gradle#L167-L172

prolok commented 1 year ago

I have tried this already, the app can be built successfully but crashed once it is just launched.

Here the packaginOptions I added

    packagingOptions {
        // file name depend on your error
        pickFirst 'lib/arm64-v8a/libc++_shared.so'
        pickFirst 'lib/armeabi-v7a/libc++_shared.so'
        pickFirst 'lib/x86/libc++_shared.so'
        pickFirst 'lib/x86_64/libc++_shared.so'
        pickFirst 'lib/arm64-v8a/libfbjni.so'
        pickFirst 'lib/armeabi-v7a/libfbjni.so'
        pickFirst 'lib/x86/libfbjni.so'
        pickFirst 'lib/x86_64/libfbjni.so'
    }

And below are my logs:

2022-11-04 15:31:59.479 566-1755/? I/ActivityTaskManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.exampleapp/.MainActivity bnds=[851,624][1059,982]} from uid 10138
2022-11-04 15:31:59.516 566-625/? D/CoreBackPreview: Window{fb61565 u0 Splash Screen com.exampleapp}: Setting back callback OnBackInvokedCallbackInfo{mCallback=android.window.IOnBackInvokedCallback$Stub$Proxy@2539eeb, mPriority=0}
2022-11-04 15:31:59.518 566-593/? I/ActivityManager: Start proc 9626:com.exampleapp/u0a169 for pre-top-activity {com.exampleapp/com.exampleapp.MainActivity}
2022-11-04 15:31:59.527 9626-9626/? I/com.exampleapp: Late-enabling -Xcheck:jni
2022-11-04 15:31:59.577 566-625/? I/AppsFilter: interaction: PackageSetting{2b321de com.exampleapp/10169} -> PackageSetting{6805d5c com.google.android.apps.nexuslauncher/10138} BLOCKED
2022-11-04 15:31:59.596 9626-9626/? W/re-initialized>: type=1400 audit(0.0:27): avc: granted { execute } for path="/data/data/com.exampleapp/code_cache/startup_agents/4cead168-agent.so" dev="dm-34" ino=139356 scontext=u:r:untrusted_app_30:s0:c169,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c169,c256,c512,c768 tclass=file app=com.exampleapp
2022-11-04 15:31:59.608 9626-9626/com.exampleapp W/com.exampleapp: DexFile /data/data/com.exampleapp/code_cache/.studio/instruments-962d6e1a.jar is in boot class path but is not in a known location
2022-11-04 15:31:59.609 9626-9626/com.exampleapp V/studio.deploy: Applying transforms with cached classes
2022-11-04 15:31:59.613 9626-9626/com.exampleapp W/com.exampleapp: Redefining intrinsic method java.lang.Thread java.lang.Thread.currentThread(). This may cause the unexpected use of the original definition of java.lang.Thread java.lang.Thread.currentThread()in methods that have already been compiled.
2022-11-04 15:31:59.613 9626-9626/com.exampleapp W/com.exampleapp: Redefining intrinsic method boolean java.lang.Thread.interrupted(). This may cause the unexpected use of the original definition of boolean java.lang.Thread.interrupted()in methods that have already been compiled.
2022-11-04 15:31:59.614 9626-9626/com.exampleapp D/CompatibilityChangeReporter: Compat change id reported: 171979766; UID 10169; state: ENABLED
2022-11-04 15:31:59.625 9626-9626/com.exampleapp W/ziparchive: Unable to open '/data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/base.dm': No such file or directory
2022-11-04 15:31:59.625 9626-9626/com.exampleapp W/ziparchive: Unable to open '/data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/base.dm': No such file or directory
2022-11-04 15:31:59.759 9626-9626/com.exampleapp V/GraphicsEnvironment: ANGLE Developer option for 'com.exampleapp' set to: 'default'
2022-11-04 15:31:59.760 9626-9626/com.exampleapp V/GraphicsEnvironment: ANGLE GameManagerService for com.exampleapp: false
2022-11-04 15:31:59.760 9626-9626/com.exampleapp V/GraphicsEnvironment: Neither updatable production driver nor prerelease driver is supported.
2022-11-04 15:31:59.762 9626-9626/com.exampleapp D/NetworkSecurityConfig: Using Network Security Config from resource network_security_config debugBuild: true
2022-11-04 15:31:59.763 9626-9626/com.exampleapp D/NetworkSecurityConfig: Using Network Security Config from resource network_security_config debugBuild: true
2022-11-04 15:31:59.772 9626-9626/com.exampleapp V/fb-UnpackingSoSource: locked dso store /data/user/0/com.exampleapp/lib-main
2022-11-04 15:31:59.773 9626-9626/com.exampleapp I/fb-UnpackingSoSource: dso store is up-to-date: /data/user/0/com.exampleapp/lib-main
2022-11-04 15:31:59.773 9626-9626/com.exampleapp V/fb-UnpackingSoSource: releasing dso store lock for /data/user/0/com.exampleapp/lib-main
2022-11-04 15:31:59.782 9626-9626/com.exampleapp W/unknown:ReactInstanceManagerBuilder: You're not setting the JS Engine Resolution Algorithm. We'll try to load JSC first, and if it fails we'll fallback to Hermes
2022-11-04 15:31:59.783 9626-9626/com.exampleapp V/SoLoader: libjscexecutor.so not found on /data/data/com.exampleapp/lib-main
2022-11-04 15:31:59.783 9626-9626/com.exampleapp D/SoLoader: libjscexecutor.so found on /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64
2022-11-04 15:31:59.783 9626-9626/com.exampleapp D/SoLoader: Not resolving dependencies for libjscexecutor.so
2022-11-04 15:31:59.783 9626-9626/com.exampleapp W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: library "libjsc.so" not found: needed by /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64/libjscexecutor.so in namespace classloader-namespace
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at java.lang.Runtime.load0(Runtime.java:929)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at java.lang.System.load(System.java:1625)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader$1.load(SoLoader.java:558)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.DirectorySoSource.loadLibraryFrom(DirectorySoSource.java:110)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.ApplicationSoSource.loadLibrary(ApplicationSoSource.java:91)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1067)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:20)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:363)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.exampleapp.MainApplication.onCreate(MainApplication.java:60)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1266)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6779)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2132)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.os.Handler.dispatchMessage(Handler.java:106)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.os.Looper.loopOnce(Looper.java:201)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.os.Looper.loop(Looper.java:288)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread.main(ActivityThread.java:7892)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at java.lang.reflect.Method.invoke(Native Method)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp W/System.err:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
2022-11-04 15:31:59.784 9626-9626/com.exampleapp E/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found: needed by /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64/libjscexecutor.so in namespace classloader-namespace result: 0
2022-11-04 15:31:59.785 9626-9626/com.exampleapp V/SoLoader: libhermes.so not found on /data/data/com.exampleapp/lib-main
2022-11-04 15:31:59.785 9626-9626/com.exampleapp D/SoLoader: libhermes.so found on /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64
2022-11-04 15:31:59.785 9626-9626/com.exampleapp D/SoLoader: Not resolving dependencies for libhermes.so
2022-11-04 15:31:59.788 9626-9626/com.exampleapp V/SoLoader: libhermes-executor-debug.so not found on /data/data/com.exampleapp/lib-main
2022-11-04 15:31:59.788 9626-9626/com.exampleapp D/SoLoader: libhermes-executor-debug.so found on /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64
2022-11-04 15:31:59.788 9626-9626/com.exampleapp D/SoLoader: Not resolving dependencies for libhermes-executor-debug.so
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_ZTVN6hermes2vm12CrashManagerE" referenced by "/data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64/libhermes-executor-debug.so"...
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at java.lang.Runtime.load0(Runtime.java:929)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at java.lang.System.load(System.java:1625)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader$1.load(SoLoader.java:558)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.DirectorySoSource.loadLibraryFrom(DirectorySoSource.java:110)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.ApplicationSoSource.loadLibrary(ApplicationSoSource.java:91)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1067)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.hermes.reactexecutor.HermesExecutor.loadLibrary(HermesExecutor.java:27)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:19)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.hermes.reactexecutor.HermesExecutor.loadLibrary(HermesExecutor.java:23)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:369)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.exampleapp.MainApplication.onCreate(MainApplication.java:60)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1266)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6779)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2132)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.os.Handler.dispatchMessage(Handler.java:106)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.os.Looper.loopOnce(Looper.java:201)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.os.Looper.loop(Looper.java:288)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at android.app.ActivityThread.main(ActivityThread.java:7892)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at java.lang.reflect.Method.invoke(Native Method)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp W/System.err:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
2022-11-04 15:31:59.791 9626-9626/com.exampleapp E/SoLoader: couldn't find DSO to load: libhermes-executor-debug.so caused by: dlopen failed: cannot locate symbol "_ZTVN6hermes2vm12CrashManagerE" referenced by "/data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64/libhermes-executor-debug.so"... result: 0
2022-11-04 15:31:59.791 9626-9626/com.exampleapp V/SoLoader: libhermes-executor-release.so not found on /data/data/com.exampleapp/lib-main
2022-11-04 15:31:59.791 9626-9626/com.exampleapp V/SoLoader: libhermes-executor-release.so not found on /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64
2022-11-04 15:31:59.791 9626-9626/com.exampleapp V/SoLoader: libhermes-executor-release.so not found on /system/lib64
2022-11-04 15:31:59.792 9626-9626/com.exampleapp V/SoLoader: libhermes-executor-release.so not found on /vendor/lib64
2022-11-04 15:31:59.792 9626-9626/com.exampleapp E/SoLoader: couldn't find DSO to load: libhermes-executor-release.so
        SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/com.exampleapp/lib-main flags = 1]
        SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64 flags = 0]
        SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
        SoSource 3: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
        Native lib dir: /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64
     result: 0
2022-11-04 15:31:59.792 9626-9626/com.exampleapp D/AndroidRuntime: Shutting down VM

    --------- beginning of crash
2022-11-04 15:31:59.793 9626-9626/com.exampleapp E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.exampleapp, PID: 9626
    java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes-executor-release.so
        SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/com.exampleapp/lib-main flags = 1]
        SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64 flags = 0]
        SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
        SoSource 3: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
        Native lib dir: /data/app/~~5gCPo3-5mWdxmMKrRW3ugw==/com.exampleapp-A5cdAo5QynDpJZbbA4OD1w==/lib/arm64
     result: 0
        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1127)
        at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
        at com.facebook.hermes.reactexecutor.HermesExecutor.loadLibrary(HermesExecutor.java:30)
        at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:19)
        at com.facebook.hermes.reactexecutor.HermesExecutor.loadLibrary(HermesExecutor.java:23)
        at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:369)
        at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
        at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
        at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
        at com.exampleapp.MainApplication.onCreate(MainApplication.java:60)
        at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1266)
        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6779)
        at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2132)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loopOnce(Looper.java:201)
        at android.os.Looper.loop(Looper.java:288)
        at android.app.ActivityThread.main(ActivityThread.java:7892)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
2022-11-04 15:31:59.794 566-916/? W/ActivityTaskManager:   Force finishing activity com.exampleapp/.MainActivity
2022-11-04 15:31:59.824 566-4907/? I/ActivityManager: Process com.exampleapp (pid 9626) has died: fg  TOP 
2022-11-04 15:31:59.849 566-3929/? D/WindowManager: relayoutVisibleWindow: Window{fb61565 u0 Splash Screen com.exampleapp EXITING} mAnimatingExit=true, mRemoveOnExit=true, mDestroying=false
2022-11-04 15:32:00.095 566-585/? W/InputManager-JNI: Input channel object 'fb61565 Splash Screen com.exampleapp (client)' was disposed without first being removed with the input manager!
2022-11-04 15:32:00.296 566-584/? W/ActivityTaskManager: Activity top resumed state loss timeout for ActivityRecord{df3a7a9 u0 com.exampleapp/.MainActivity} t-1 f}}

I posted this up in the releases-coordination channel of the react-native contributors discord as that is where a lot of the release work (or news about the work) is coordinated.

In the meantime, there may be some tricks to play with regard to excluding files, if someone has time to try:

https://stackoverflow.com/questions/29793992/exclude-native-library-in-gradle-android-build

Historically, react-native use to sometimes use a "pickFirst" directive, and that may be possible here, to force an election between the two similarly named .so files, this bears an experiment if someone affected has time (I do not, just trying to cross-pollinate here since this is undoubtedly a hot issue with many people interested / blocked right now)

https://github.com/facebook/react-native/blob/83425fa72f1f9a12f6b6deefd66fa8bd154a3651/template/android/app/build.gradle#L167-L172

mikehardy commented 1 year ago

All reports of crash should be accompanied by trace from adb logcat, also, I proposed two solutions, so saying you tried "this" is ambiguous, what exactly did you try, preferably as snippet from your build.gradle [edit to add: of course I'm happy to hear anyone is trying anything of course, thank you, just want to keep this as technically precise+accurate as possible with regard to tests + results reporting]

bkasten-rbi commented 1 year ago

@mikehardy I appreciate the advice. I'm just a little concerned that a rc release was able to suddenly break several projects CI builds. Is it truly the right solution that consumers need to fix this locally?

afturner commented 1 year ago

Is it truly the right solution that consumers need to fix this locally?

Agreed. I understand conversations are happening on a Discord; however, as far as I understand these conversations are not accessible to the general public.

As a short term fix, would removing the pre-release tag fix the issue?

prerakd commented 1 year ago

Facing crashes in my app as well since last one hour. I am using react-native@0.69.6. Facing issues with react-native-reanimated error: cannot find symbol class ReaUiImplementationProvider extends UIImplementationProvider { ^ symbol: class UIImplementationProvider

error: no suitable constructor found for UIManagerModule(ReactApplicationContext,List<ViewManager>,ReaUiImplementationProvider,int) super( ^ constructor UIManagerModule.UIManagerModule(ReactApplicationContext,ViewManagerResolver,int) is not applicable (actual and formal argument lists differ in length) constructor UIManagerModule.UIManagerModule(ReactApplicationContext,List<ViewManager>,int) is not applicable (actual and formal argument lists differ in length)

mikehardy commented 1 year ago

@bkasten-rbi absolutely not the right solution solution we hope for, that back-versions need to fix this locally, but I am a deeply pragmatic person, and it is Friday, already after business hours in Europe (where many of the release folks live) so I'm casting about for any workaround as this is clearly a Very Big Deal.

I'm not even sure what the root cause is yet, just trying to mention the gradle adjustements I'm aware of that might unblock people if they are stuck

jaredh commented 1 year ago

This is happening because all the templates reference the React Native dependency by range, like implementation 'com.facebook.react:react-native:+'. Usually this dependency gets resolved from the local Maven repo in ./node_modules/react-native/android but since it has been published to Maven Central it's now grabbing the very latest RC.

You can resolve this problem by forcing the React Native dependency to the version you expect with something like this implementation 'com.facebook.react:react-native:0.68.2!!' in your app's Gradle file. The !! is shorthand for restricting Gradle from upgrading if your project or its transitive dependencies depend on a newer version.

AFAIK Maven Central is immutable and the published dependency can't removed so this might be the only solution.

mikehardy commented 1 year ago

It is true the Discord is not generally accessible - I only mentioned it to note for interested parties here (where the work should take place and likely will) that there had been notice

As a short term fix, would removing the pre-release tag fix the issue?

It could be, I have no authority to do so - the people that do are on that Discord though and I've seen as of this typing some recognition from them that they've seen this, so hopefully there will be a valid workaround (perhaps a tag removal) soon.

It may be that some artifact was published somewhere and simply removing the tag will not help, as mentioned just above there has not been a clearly identified root cause of exactly why old versions of react-native would be affected by / include transitive dependencies of the new version yet. So it's all speculation in the absence of a correct technical analysis.

Grohden commented 1 year ago

Using RN 67~ or something, our build has been reporting the new RC tag...

* What went wrong:
Execution failed for task ‘:app:mergeDebugNativeLibs’.
> A failure occurred while executing com.android.build.gradle.internal.tasks.MergeJavaResWorkAction
  > 2 files found with path ‘lib/armeabi-v7a/libfbjni.so’ from inputs:
   - /Users/.../.gradle/caches/transforms-3/17edb190053f69870cd009f3519f9d76/transformed/jetified-react-native-0.71.0-rc.0-debug/jni
   - /Users/.../.gradle/caches/transforms-3/2506e1f939972b42e27e90aeb1b1d9f5/transformed/jetified-fbjni-0.3.0/jni
   If you are using jniLibs and CMake IMPORTED targets, see
   https://developer.android.com/r/tools/jniLibs-vs-imported-targets

I'm seeing that a lot of libs declare their dependency (?) in RN as api 'com.facebook.react:react-native:+', so somehow that dep ended up going to all apps everywhere, but I'm not being able to track where that original package is being declared

does that have anything related to the changes in the package json here?

mikehardy commented 1 year ago

I think this has to do with the publish of the RC to maven central - perhaps that is the root cause, perhaps that is something that does not normally happen such that the + range works normally but it is biting everyone now that a public repository has a newer dep.

[edit: confirmed it was published to maven central, that is triggering this: https://repo1.maven.org/maven2/com/facebook/react/react-native/]

I want to amplify the comment from @jaredh is this could use some success reports if others try it:

You can resolve this problem by forcing the React Native dependency to the version you expect with something like this implementation 'com.facebook.react:react-native:0.68.2!!' in your app's Gradle file. The !! is shorthand for restricting Gradle from upgrading if transitive dependencies depend on a newer version.

afturner commented 1 year ago

I can confirm that setting the following works:

configurations.all {
  resolutionStrategy {
    force 'com.facebook.react:react-native:0.68.2'
  }
}

I'm doing some more testing but would appreciate any other confirmations. Thanks for the information @jaredh

ref: https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html

mishkeTz commented 1 year ago

Might help.

RN: 0.63.4

Console output while building:

[0] Warning: Mapping new ns http://schemas.android.com/repository/android/common/02 to old ns http://schemas.android.com/repository/android/common/01
[0] Warning: Mapping new ns http://schemas.android.com/repository/android/generic/02 to old ns http://schemas.android.com/repository/android/generic/01
[0] Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/addon2/02 to old ns http://schemas.android.com/sdk/android/repo/addon2/01
[0] Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/repository2/02 to old ns http://schemas.android.com/sdk/android/repo/repository2/01
[0] Warning: Mapping new ns http://schemas.android.com/sdk/android/repo/sys-img2/02 to old ns http://schemas.android.com/sdk/android/repo/sys-img2/01
[0] e: Incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors
[0] e: /Users/nikola/.gradle/caches/transforms-2/files-2.1/57040b993d0ff1d7ebeea9a8556437c0/jetified-react-native-0.71.0-rc.0-debug-api.jar!/META-INF/ReactAndroid_debug.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.2.
[0] e: /Users/nikola/.gradle/caches/transforms-2/files-2.1/701915f0cc957c514ff63496a3eef651/jetified-kotlin-stdlib-1.6.10.jar!/META-INF/kotlin-stdlib.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.2.
[0] e: /Users/nikola/.gradle/caches/transforms-2/files-2.1/9a2dbde87fe3303b251f9985951824c3/jetified-kotlin-stdlib-jdk8-1.6.10.jar!/META-INF/kotlin-stdlib-jdk8.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.2.
[0] e: /Users/nikola/.gradle/caches/transforms-2/files-2.1/afc3d113e647c23d065090f58d02711a/jetified-kotlin-stdlib-jdk7-1.6.10.jar!/META-INF/kotlin-stdlib-jdk7.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.2.
[0] e: /Users/nikola/.gradle/caches/transforms-2/files-2.1/d2f890a68206b260c13eff83d1c8172c/jetified-kotlin-stdlib-common-1.6.10.jar!/META-INF/kotlin-stdlib-common.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.2.
[0] e: /Users/nikola/user/project/app/node_modules/@invertase/react-native-apple-authentication/android/src/main/java/com/RNAppleAuthentication/FormInterceptorInterface.kt: (14, 116): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.6.0, expected version is 1.4.2.
[0] The class is loaded from /Users/nikola/.gradle/caches/transforms-2/files-2.1/701915f0cc957c514ff63496a3eef651/jetified-kotlin-stdlib-1.6.10.jar!/kotlin/Unit.class
[0] e: /Users/nikola/user/project/app/node_modules/@invertase/react-native-apple-authentication/android/src/main/java/com/RNAppleAuthentication/FormInterceptorInterface.kt: (17, 27): Unresolved reference: split
[0] e: /Users/nikola/user/project/app/node_modules/@invertase/react-native-apple-authentication/android/src/main/java/com/RNAppleAuthentication/FormInterceptorInterface.kt: (18, 38): Unresolved reference: it
mikehardy commented 1 year ago

@afturner based on my lookup just now to cross-check that the artifact really does exist on maven central this appears to be the root cause:

Thus I think either workaround - pinning the version in the dep or setting it via resolution strategy are fully functional

bkasten-rbi commented 1 year ago

@mikehardy thank you!

in addition to that, do we think its possible to remove it from maven until the versioning issue is sorted out?

mikehardy commented 1 year ago

@bkasten-rbi maven is immutable. The damage is done, there is no undoing it 😢 (link from jaredh https://central.sonatype.org/faq/can-i-change-a-component/#question)

mikehardy commented 1 year ago

I added the workaround in the main description so it is the first thing everyone sees, and added that we have a workaround in the title, hopefully no offense @markholland but this is going to get hit all weekend long maybe for longer and I want people to see the workaround immediately to waste as little of people's time as possible.

afturner commented 1 year ago

Since discussions are happening in Discord, let me throw my 2 cents out there:

mikehardy commented 1 year ago

I am also on a CI team and do release engineering all over, and I generally avoid Fridays for this reason :-), I personally agree but also am not on the react-native release team that does the releases (I just help qualify them) so my agreement does not mean that much.

Your second part is interesting though - + has bitten a few communities a few times, it is very dangerous. Do you have a concrete proposal for gradle pulling in the node_modules react-native version every time without a + version?

mikehardy commented 1 year ago

I also want to emphasize that being react-native "release person" is a nearly zero-thanks job and takes quite a bit of time. The person doing this is a volunteer that just recently started training for it to increase the pool of people that can release (I think the current pool size is literally 2, so this would make 3 people that can do it). That is all to say that even in gigantic communities like react-native, vital things sometimes fall down to just a couple people and everyone is doing it with the good of the community at heart.

If you've even been a release engineer you know this is a nightmare, so everyone please take a breath and try to balance the irritation of this build break with gratitude that react-native will keep moving along, and hey, maybe without the + dependencies for 0.71 if it can be removed somehow.

Happy Friday? 😆

afturner commented 1 year ago

Your second part is interesting though - + has bitten a few communities a few times, it is very dangerous. Do you have a concrete proposal for gradle pulling in the node_modules react-native version every time without a + version?

Not at the moment, no. Gradle could read node_modules/react-native/package.json and pull the version but that feels awfully hacky and brittle.

bhandanyan-nomad commented 1 year ago

Should the suggested resolutionStrategy workaround fix all possible manifestations of this issue? The only thing that has worked for me so far is directly patching my dependencies(react-native-auth0) build.gradle

mikehardy commented 1 year ago

Here is another possible solution, perhaps the best possible solution (from @cortinico on discord), in your android/buld.gradle

https://github.com/facebook/react-native/blob/3e75c0b3baa265a7b5431cd2d304389f9a3faa44/template/android/build.gradle#L43-L49


        mavenCentral {
            // We don't want to fetch react-native from Maven Central as there are
            // older versions over there.
            content {
                excludeGroup "com.facebook.react"
            }
        }

That will stop the new version from resolving, and revert back to local node_modules resolution of react-native

afturner commented 1 year ago

That will stop the new version from resolving, and revert back to local node_modules resolution of react-native

At least in our build.gradle this is already defined and it did not make a difference.

We have a pretty complicated build, however, with many moving parts so maybe there's something else going on for my team. The resolutionStrategy approach has just passed on CI so at least I can confirm it works for us 😅

mikehardy commented 1 year ago

It appears other repos have unrestricted maven repo definitions for mavenCentral, it appears react-native-reanimated is one such, so react-native may still resolve to mavenCentral even if you restrict it in your main android/bulid.gradle ?

Those repos may need build.gradle patch-package patches temporarily, or, just use resolutionStrategy to pin the version.

reanimated example: https://github.com/software-mansion/react-native-reanimated/blob/8933a00fce0fa2b3f636c83f75ad708bfbb3e9d0/android/build.gradle#L416

jesboat commented 1 year ago

Even if it were possible for the React team to remove the bad version from Maven Central, that wouldn't work, because the bad version might already be cached in many organizations' caching repos, or machine-local caches.

Pretty much the only thing that can be done which fixes the problem for everybody is to publish an artifact to Maven Central which has a newer version than the broken release, but the same code as previous real release. For example, release 0.71.rc.1 (or maybe just 0.71) with the same code as the most recent 0.70 release.

mikehardy commented 1 year ago

@jesboat that cannot work though, as the + would then resolve that, but it would only be the right version for people on that exact version.

resolutionStrategy as defined at the top of this issue appears to be the current best solution based on Discord discussion. It is not great because now you have the version hard-coded in there, but it should work without needing patches in bunches of modules.

Apparently 0.71 will fix all this either way

There may be a gradle stanza you can author to force your app level repo excludes to all sub-projects, but resolutionStrategy will do to get people moving, it seems

inckie commented 1 year ago

It can be suppressed on repository configuration level for all projects.

        mavenCentral() {
            content {
                excludeGroup "com.facebook.react"
            }
        }

In theory react native should be always forced to be only imported from local m2, setting it to includeGroup "com.facebook.react" instead, but its not so easy to limit that

https://docs.gradle.org/current/userguide/declaring_repositories.html#declaring_content_exclusively_found_in_one_repository

Update: yes, exclusive content also works unless someone needs one of few other artifacts in same group.

        exclusiveContent {
            forRepository {
                maven {
                    url "$rootDir/node_modules/react-native/android"
                }
            }
            filter {
                // this repository *only* contains artifacts with group "my.company"
                includeGroup "com.facebook.react"
            }
        }
connorpmullins commented 1 year ago

Thanks for helping with the resolution @mikehardy et. al. @cipolleschi, hope you're alright man. Thanks for working on RN.

prolok commented 1 year ago

Want to add what I tried with @mikehardy 's workaround, but I found the other modules still using 0.71.0-rc.0, and that made my app crash as the app is running with version 0.66.4

Screen Shot 2022-11-04 at 4 57 48 PM

and the error is coming from react-native-document-picker:

2022-11-04 16:35:17.813 13297-13297/com.projectrey E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.projectrey, PID: 13297
    java.lang.NoSuchMethodError: No virtual method getExceptionHandler()Lcom/facebook/react/bridge/JSExceptionHandler; in class Lcom/facebook/react/bridge/ReactContext; or its super classes (declaration of 'com.facebook.react.bridge.ReactContext' appears in /data/app/~~ReBltVX9TGgc9uXlc7d7iw==/com.projectrey-wVNckE02VYRRVyD-QYVLJg==/base.apk)
        at com.reactnativedocumentpicker.DocumentPickerModule$ProcessDataTask.<init>(DocumentPickerModule.java:234)
        at com.reactnativedocumentpicker.DocumentPickerModule.onShowActivityResult(DocumentPickerModule.java:218)
        at com.reactnativedocumentpicker.DocumentPickerModule$1.onActivityResult(DocumentPickerModule.java:76)
        at com.facebook.react.bridge.ReactContext.onActivityResult(ReactContext.java:333)
        at com.facebook.react.ReactInstanceManager.onActivityResult(ReactInstanceManager.java:785)
        at com.facebook.react.ReactDelegate.onActivityResult(ReactDelegate.java:90)
        at com.facebook.react.ReactActivityDelegate.onActivityResult(ReactActivityDelegate.java:113)
        at com.facebook.react.ReactActivity.onActivityResult(ReactActivity.java:70)
        at android.app.Activity.dispatchActivityResult(Activity.java:8608)
        at android.app.ActivityThread.deliverResults(ActivityThread.java:5337)
        at android.app.ActivityThread.handleSendResult(ActivityThread.java:5383)
        at android.app.servertransaction.ActivityResultItem.execute(ActivityResultItem.java:67)
        at android.app.servertransaction.ActivityTransactionItem.execute(ActivityTransactionItem.java:45)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2306)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loopOnce(Looper.java:201)
        at android.os.Looper.loop(Looper.java:288)
        at android.app.ActivityThread.main(ActivityThread.java:7892)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
mikehardy commented 1 year ago

@prolok we are currently furiously iterating on a few variants.

You might try this in your android/build.gradle (top level) file, in the allprojects block, it has reported success even with reanimated etc mixed in, also has reported success with expo now (fix in progress there, they are listening closely)

allprojects {
    configurations.all {
        resolutionStrategy {
            force 'com.facebook.react:react-native:<your version>'
        }
    }
    repositories {
    // ...
    }
}
mikehardy commented 1 year ago

I have updated the guidance at the top of the issue, this last version appears to be the "most reported success" solution. Any experimental results that contradict that are welcome - we hope it works for everyone though.

leonardorib commented 1 year ago

@prolok we are currently furiously iterating on a few variants.

You might try this in your android/build.gradle (top level) file, in the allprojects block, it has reported success even with reanimated etc mixed in, also has reported success with expo now (fix in progress there, they are listening closely)

allprojects {
    configurations.all {
        resolutionStrategy {
            force 'com.facebook.react:react-native:<your version>'
        }
    }
    repositories {
    // ...
    }
}

I can confirm this worked! I was trying by adding it to android/app/build.gradle but now that I tried at android/build.gradle it finally worked! Thank you

andrejborstnik commented 1 year ago

Just reporting that replacing all mavenCentral()-s (including those in node_modules) with 

mavenCentral {
    content {
         excludeGroup "com.facebook.react"
    }
}

worked for us. We used this simple (ugly) replacement on post-install if it helps anyone. 

find ./node_modules -type f -name "*.gradle" -exec sed -i -e 's/mavenCentral()/mavenCentral {content {excludeGroup "com.facebook.react"}}/g' {} \;
mikehardy commented 1 year ago

@andrejborstnik interesting! I can see how that can work, but it may cause problems in some CI platforms like bitrise where I think the files are readonly...so be careful

@brentvatne @ Expo proposes this as a refinement to avoid the hard coded version, it is the same as the previous best-known solution but now with dynamic version powers, otherwise same idea in your android/buld.gradle file

def REACT_NATIVE_VERSION = new File(['node', '--print',"JSON.parse(require('fs').readFileSync(require.resolve('react-native/package.json'), 'utf-8')).version"].execute(null, rootDir).text.trim())

allprojects {
    configurations.all {
        resolutionStrategy {
            force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
        }
    }
wood1986 commented 1 year ago

I know this is rare case. If people has patch to the java files, their patch never be able to be applied

mgeshagrath commented 1 year ago

@andrejborstnik interesting! I can see how that can work, but it may cause problems in some CI platforms like bitrise where I think the files are readonly...so be careful

@brentvatne @ Expo proposes this as a refinement to avoid the hard coded version, it is the same as the previous best-known solution but now with dynamic version powers, otherwise same idea in your android/buld.gradle file

def REACT_NATIVE_VERSION = new File(['node', '--print',"JSON.parse(require('fs').readFileSync(require.resolve('react-native/package.json'), 'utf-8')).version"].execute(null, rootDir).text.trim())

allprojects {
    configurations.all {
        resolutionStrategy {
            force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
        }
    }

This worked for me. V: 0.64.1

leofolive commented 1 year ago

@andrejborstnik interesting! I can see how that can work, but it may cause problems in some CI platforms like bitrise where I think the files are readonly...so be careful

@brentvatne @ Expo proposes this as a refinement to avoid the hard coded version, it is the same as the previous best-known solution but now with dynamic version powers, otherwise same idea in your android/buld.gradle file

def REACT_NATIVE_VERSION = new File(['node', '--print',"JSON.parse(require('fs').readFileSync(require.resolve('react-native/package.json'), 'utf-8')).version"].execute(null, rootDir).text.trim())

allprojects {
    configurations.all {
        resolutionStrategy {
            force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
        }
    }

This worked on all my projects. Tks!

prolok commented 1 year ago

Here is another possible solution, perhaps the best possible solution (from @cortinico on discord), in your android/buld.gradle

https://github.com/facebook/react-native/blob/3e75c0b3baa265a7b5431cd2d304389f9a3faa44/template/android/build.gradle#L43-L49

        mavenCentral {
            // We don't want to fetch react-native from Maven Central as there are
            // older versions over there.
            content {
                excludeGroup "com.facebook.react"
            }
        }

That will stop the new version from resolving, and revert back to local node_modules resolution of react-native

Finally this work for me.

Really thanks for all of you for providing the workarounds!

gnprice commented 1 year ago

Here is another possible solution, perhaps the best possible solution (from @cortinico on discord), in your android/build.gradle

This was very helpful!

For me, it was important also to apply that to android/app/build.gradle (note app/), where I also had a mavenCentral() call:

 repositories {
-    mavenCentral()
+    mavenCentral {
+        // We want react-native from the local Maven repo in node_modules/react-native/ --
+        // not from Maven Central.
+        content {
+            excludeGroup "com.facebook.react"
+        }
+    }
 }

Happily for us there was no need to go as far as @andrejborstnik reported:

Just reporting that replacing all mavenCentral()-s (including those in node_modules) with

Lots of dependencies in node_modules do have mavenCentral() calls, but (for us) apparently none of them had direct Gradle dependencies on com.facebook.react:react-native -- which makes sense. So that made this a very clean fix.

gnprice commented 1 year ago

https://docs.gradle.org/current/userguide/declaring_repositories.html#declaring_content_exclusively_found_in_one_repository

Ah, this is an even better fix -- thanks @inckie !

Here's what it looks like explicitly, in android/build.gradle (edit: or to view as a diff, see the PR I just sent to apply this fix to the template app):

allprojects {
    repositories {
        exclusiveContent {
            // We get React Native's Android binaries exclusively through npm,
            // from a local Maven repo inside node_modules/react-native/.
            // (The use of exclusiveContent prevents looking elsewhere like Maven Central
            // and potentially getting a wrong version.)
            filter {
                includeGroup "com.facebook.react"
            }
            forRepository {
                maven {
                    url "$rootDir/../node_modules/react-native/android"
                }
            }
        }

That replaces the following which is already there in the template app:

allprojects {
    repositories {
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url("$rootDir/../node_modules/react-native/android")
        }

The exclusiveContent expresses exactly what we want here:

With that snippet in place, there's no need for excludeGroup on any individual mavenCentral calls, and no need for resolutionStrategy specifying the React Native version.