react-native: [HAS WORKAROUND] Android build fails since 0.71.0-rc.0 tag added

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.

@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
        }
    }

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? 😆

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:

• The Gradle dependencies comprising React Native should come from that local Maven repo inside node_modules/react-native/.
• They should not come from any other repositories of any kind, no matter what other repositories might be declared in other Gradle scripts anywhere in the build.

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.

@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 {
    // ...
    }
}

@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)

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

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 😅

@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

@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?

@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

Hey everyone! 👋

I’m happy to hear the workarounds (one for really old / <= 6.1 gradle, one for current gradle) are working. We are 99% certain now that we have solutions that should work for all cases.

Going forward please only comment if you have a failure case - something that is not handled by either of the workarounds on #35210 so the comments are focused and the notifications are only generated for things that really need attention.

Thanks!

I have left all the other workaround attempts up as each of them can fix the build for people under certain circumstances

but the best known fix is now at #35210 courtesy of @inckie and @gnprice and @cortinico - you should use that if possible

@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!

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.

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

• Could Friday releases generally be avoided? I do, however, understand that publishing to Maven was an accident/not typical.
• Is it reasonable for templates to utilize +? Is there a better way for templates to use the version expected from NodeJS?
  • I am not terribly experienced with RN, I’m on a CI team, so this might be an inane question 😉

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

• typical react-native build.gradle includes + range
• typical react-native publish does not publish to maven central
• this RC was published to maven central and has a higher version than local
• typical react-native build.gradle thus pulls the new (unwanted) RC version from maven central
• build fails

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

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

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!

@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

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"
            }
        }

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 thank you so much for your help!!! it worksss 😃

Hi , To resolve the issue this method worked for me , hope this will help you guys too!! step 1 : In package.json or node_modules inside copy the version of react native that you have step 2 : In the project , android/app/build.gradle the existing would be like this **com.facebook.react:react-native:+** Change this to **com.facebook.react:react-native:<react version>!!** step 3 : Run the below command cd android & ./gradlew clean
step 4 : Run this command react-native run-android

Add this fix to your android -> build.gradle file as follows:

buildscript {
    // ...
}


allprojects {
    repositories {
       exclusiveContent {
           filter {
               includeGroup "com.facebook.react"
           }
           forRepository {
               maven {
                   url "$rootDir/../node_modules/react-native/android"
               }
           }
       }
        // ...
    }
}

What this fix will do is apply an exclusiveContent resolution rule that will force the resolution of React Native Android library, to use the one inside node_modules

Ref: Fix and updates on Android build failures happening since Nov 4th 2022 #35210

android { packagingOptions { pickFirst ‘lib/arm64-v8a/libc++_shared.so’ pickFirst ‘lib/arm64-v8a/libfbjni.so’ pickFirst ‘lib/armeabi-v7a/libc++_shared.so’ pickFirst ‘lib/armeabi-v7a/libfbjni.so’ pickFirst ‘lib/x86/libc++_shared.so’ pickFirst ‘lib/x86/libfbjni.so’ pickFirst ‘lib/x86_64/libc++_shared.so’ pickFirst ‘lib/x86_64/libfbjni.so’ } …//other code }

above code in android/app/build.gradle fixed my problem

I am using react native version 0.69.5

Update: I was able to make the build but it is crashing the app and looking for the solution. if it worked I will update here.

Another update :

Below code worked perfectly for me.

Add this to your android/build.gradle,

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 } }

The file you should be looking at is android/build.gradle

 allprojects {
     repositories {
-        mavenCentral()
+        mavenCentral { content { excludeGroup 'com.facebook.react' } }
     }
 }

This works well for simple projects. However, as several people pointed out above, it might not work when the React Native app has dependencies that include native modules with a dependency on kotlin-stdlib (and mavenCentral in repositories). Errors such as the following will be printed to console:

> Task :react-native-webview:compileDebugKotlin FAILED
e: Incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors
e: ~/.gradle/caches/transforms-3/123/transformed/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.1.15.

My guess is that’s because react-native:0.71.0-rc.0 contains a compile dependency on kotlin-stdlib-jdk8:1.6.10: https://search.maven.org/artifact/com.facebook.react/react-native/0.71.0-rc.0/pom

One solution without forcing anything is to fix up the problematic dependencies (subprojects) like so:

subprojects {
    if (it.name in [
            'react-native-pager-view',
            'react-native-screens',
            'react-native-webview',
    ]) {
        it.evaluate()
        it.repositories.each { repo ->
            if (repo.name == 'MavenRepo') {
                repo.content { excludeGroup 'com.facebook.react' }
            }
        }
    }
}

Over time, as those dependencies will get fixed in newer versions, entries can be removed from the list piece by piece.

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

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

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)

@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

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

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

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?

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.