Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FIXED] Android build failures No matching variant of com.facebook.react:react-native:0.71.0-rc.0 was found. #35210

Closed
cortinico opened this issue Nov 5, 2022 · 220 comments · Fixed by Expensify/App#12510
Labels
Platform: Android Android applications. Resolution: Fixed A PR that fixes this issue has been merged. RN Team

Comments

@cortinico
Copy link
Contributor

cortinico commented Nov 5, 2022

Description

Hey all,
I'd like to share an update on a series of build failures React Native & Expo users have been experiencing when building Android apps starting from November 4th 2022.

We'd like to apologize for the disruption this caused to your developer workflows. The React team is fully committed to delivering a smooth developer experience, and we take this type of issues extremely seriously.

📢 Patches for >= 0.63

We have prepared releases for all the main versions of react-native with an hotfix:

🛳 0.70.5: https://github.com/facebook/react-native/releases/tag/v0.70.5
🛳️ 0.69.7: https://github.com/facebook/react-native/releases/tag/v0.69.7
🛳 0.68.5: https://github.com/facebook/react-native/releases/tag/v0.68.5
🛳️ 0.67.5: https://github.com/facebook/react-native/releases/tag/v0.67.5
🛳️ 0.66.5: https://github.com/facebook/react-native/releases/tag/v0.66.5
🛳️ 0.65.3: https://github.com/facebook/react-native/releases/tag/v0.65.3
🛳️ 0.64.4: https://github.com/facebook/react-native/releases/tag/v0.64.4
🛳️ 0.63.5: https://github.com/facebook/react-native/releases/tag/v0.63.5

By updating to these patch versions, your Android build should start working again.

To do so, in your package.json change react-native's version to the relevant new patch (ex. if you are on 0.64.3, change to 0.64.4) and run yarn install. No other changes should be necessary, but you might want to clean your android artifacts with a cd android && ./gradlew clean before trying to re-run your Android app.

Fix for older react-native (< 0.63)

The fix above only works on gradle 6.2 and higher. Older react-native used older gradle.

You may determine your gradle version by looking in your /android/gradle/wrapper/gradle-wrapper.properties file.

If you are on an older version of react-native (for example 0.63 or earlier) that uses gradle version 6.1 or below, you must use a different workaround as gradle 6.1 does not support exclusiveContent.

Add this in the allprojects area of 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 {
            // Remove this override in 0.65+, as a proper fix is included in react-native itself.
            force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
        }
    }

Instead of using exclusiveContent, the hotfix must force the version of React Native. The recommended hotfix shells out to node to read your current version of react-native. If you hard code the version of react-native, when you upgrade your project in the future, your build will fail if you forget to remove this hotfix.

Note that this fix is fragile as the location of your package.json could be different if you are in a monorepo, and node might not be available if you use a node package manager like nvm.

Thank you @mikehardy for finding and providing this fix in your comment.

Technical Details

The issue

On November 4th 2022 we published the React Native version 0.71.0-rc0, the first release candidate for the 71 release series, on several public repositories. Specifically, this version was also published on Maven Central as we're updating our artifacts distribution strategy (technical details are explained below).

This event resulted in build failures for Android on several users as they ended up downloading the wrong React Native version (0.71.0-rc0 instead of the version they were using in their project, say 0.68.0).

The build error looks something like this:

Error: Command failed: gradlew.bat app:installDebug -PreactNativeDevServerPort=8081

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'My Project'.
Could not determine the dependencies of null.
Could not resolve all task dependencies for configuration ':classpath'.
    > Could not resolve com.facebook.react:react-native:+.
      Required by:
          project :
    > No matching variant of com.facebook.react:react-native:0.71.0-rc.0 was found. 
      The consumer was configured to find a runtime of a library compatible with Java 11, 
      packaged as a jar, and its dependencies declared externally, as well 
      as attribute 'org.gradle.plugin.api-version' with value '7.3.3' but:

Sadly, due to how older projects of React Native were created in the past, we couldn't simply re-publish older versions, and we're asking users to update their template using the fix suggested below.

Why this happened

Historically, the React Native template provided build.gradle files that contain a dependency on the React Native Android library as follows: implementation("com.facebook.react:react-native:+").

Specifically, the + part of this dependency declaration is causing Gradle to pick the highest version among all the declared repositories (often referred as Gradle Dynamic versions). Till React Native version 0.70, we were shipping a Maven Repository inside the NPM package (inside the ./android folder). Starting from 0.71, we moved such folder and uploaded it to Maven Central.

Using Gradle Dynamic versions (i.e. a + dependency) is considered an antipattern (see the various warnings and notes on this page), specifically as it can lead to scenarios like this one and generally exposes users to less-reproducible builds. This is exactly what happened in this scenario, as builds started failing without any changes to user projects.

In 0.71 we cleaned up the new app template and removed all the + dependencies (see here) and we moved the template to use the React Native Gradle Plugin, which will allow us to prevent scenarios like this from happening in the future.

Sadly, users on older versions, say 0.66.0, were still using a + version. This caused their build to query all the repositories for the highest available versions of the React Native. While the node_modules/react-native/android folder contained a valid 0.66.0 version, Gradle honoured the + version and fetched version 0.71.0-rc0 from Maven Central as it's higher from the semantic versioning ordering.

The resolutionStrategy block in the fix is forcing the version of com.facebook.react:react-native to all the projects to the one provided by the version of React Native you're effectively using.

Who is affected?

All the React Native users on versions till 0.66.x are affected.

React Native users on versions from 0.67 till 0.70 could be affected, based on which third-party library they're using.

We verified that empty projects created on versions from 0.67 till 0.70 are not affected.

However, some of your dependencies might end up causing a wrong resolution of the React Native Android library, resulting in build failures.
For instance, we verified that a project on React Native 0.68.4 works well with Reanimated 2.12.0 but fails with Reanimated 2.10.0.

We also worked with Expo to make sure that users on eas build received the aforementioned fix, so those users should not be affected.

Why React Native Android was published on Maven Central?

As mentioned, this was done as part of the implementation of the RFC #580.

The summary of that RFC is to allow us to overcome the limitation of NPM in terms of package size. Moving to Maven Central will allow us to reduce the build time for our users and distribute more granular artifacts which will end up benefitting the overall developer experience. We'll be able to share information on this in the near future.

In the initial Github Issue, several users suggest to remove the publishing from Maven Central or re-publish older artifacts to overcome the build failure without requesting a fix.

This is sadly not an option as:

  1. Maven Central is an immutable artifacts storage and doesn't allow deletion.
  2. The publishing on 0.71.0-rc0 was effectively correct. We believe this episode is essentially a "mis-configuration" in user projects, and we believe the better solution is to distribute this fix to our users.

How could this have been prevented

We were already aware of the risk of having Gradle dynamic dependencies, so since React Native 0.67 we introduced an exclude rule on the Maven Central dependency inside the default template (see here for more context):

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

React Native used to be published on Maven Central till version 0.20.1 (published in 2016). We had users in the past accidentally fetching older versions of React from Maven Central, causing their build to fail.

This exclude directive assured that you won't ever download React Native from Maven Central. However, third party libraries could declare repositories inside their repositories{} block which might not contain the exclude directive, resulting in potentially broken dependency resolution.

React Native version 0.71.0 will ship with an updated template that relies on React Native Gradle Plugin. This new integration will allow us to protect us against future distributed build failures like this one, by allowing to re-distribute updated build logic across the whole ecosystem if needed (this should protect us also against similar outages like the JCenter outage happened last year).


I'd like to thank everyone for your patience and understanding and I'd like to call out some members our our community, specifically @mikehardy, @Titozzz, @brentvatne, @inckie and all the other folks involved in the initial investigation and fix for this issue.

We'll follow up with more updates in the future if needed.

Nicola
On behalf of the React team

@enahum

This comment was marked as resolved.

@olafashade

This comment was marked as resolved.

@darkhorse-coder

This comment was marked as resolved.

@ItsAmanOP

This comment was marked as resolved.

@oleksandr-dziuban
Copy link

oleksandr-dziuban commented Nov 5, 2022

Thanks @cortinico everything is working fine.
So once our projects updated to RN 0.71+ we must remove this workaround, right?

@jouiniyassine49

This comment was marked as resolved.

@mikehardy
Copy link
Contributor

mikehardy commented Nov 5, 2022

@JodiRaina that likely indicates your gradle plugin or gradle is too old to use this advice - it appears gradle 6.1 and older does not have the exclusiveContent / include filter in the preferred solution.

If you cannot upgrade gradle (and react-native...), you might try one of the fallback workarounds for old react-native using very old gradle plugin / gradle, specifically this one, which was the best-known solution if exclusiveContent is not available / until the exclusiveContent idea occurred

#35204 (comment)


@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 - you put this in the allprojects area of 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 {
            // Remove this override in 0.66, as a proper fix is included in react-native itself.
            force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
        }
    }

Note that the exclusiveContent idea is a cleaner solution, but of course only if your gradle supports it

@devinkg

This comment was marked as resolved.

@gagal18

This comment was marked as resolved.

@mikehardy
Copy link
Contributor

mikehardy commented Nov 5, 2022

Hey everyone 👋 ! We know the fix works in almost all cases.
We have one failure case where your gradle is 6.1 or lower, with a separate workaround as described above.

There is no need to report success here as it will just clutter up the thread and hide real problems, if any.

If you have a case that does not work, then it is worth commenting and pursuing.

Thanks!

@Libero793

This comment was marked as resolved.

@mikehardy

This comment was marked as resolved.

@jhusdero
Copy link

Hey, I'm having some issues when upgrading from react-native v0.64.1 -> v0.64.4. This is the error message I am getting when trying to create a build or running ./gradlew clean in the android directory. Gradle version 7.0.2. Any help is appreciated.

**************************

FAILURE: Build failed with an exception.

* Where:
Script '~/node_modules/react-native/react.gradle' line: 360

* What went wrong:
A problem occurred evaluating script.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

Facing the same issue. updating from 0.64.2 to 0.64.4 and running ./gradlew clean yields this error

1: Task failed with an exception.
-----------
* Where:
Script '~/node_modules/react-native/react.gradle' line: 360

* What went wrong:
A problem occurred evaluating script.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.


gradlew version = 7.0.2

@ravis-farooq
Copy link

Prior to 4 November it was working fine and now when I am trying to build it by running yarn android but it is showing me.
I tried the patch also 0.66.3 => 0.66.5
I cleaned the gradle
Removed the node_modules

But I am getting this error everytime

/Users/dev/Desktop/Abc Projects/aargee/node_modules/react-native-webrtc/android/src/main/java/com/oney/WebRTCModule/VideoTrackAdapter.java:5: error: cannot access VideoFrame
import org.webrtc.VideoFrame;
                 ^
  bad class file: /Users/dev/.gradle/caches/transforms-2/files-2.1/8af035e80c335f19cef40762b46ee77a/jetified-libwebrtc.jar(org/webrtc/VideoFrame.class)
    class file has wrong version 55.0, should be 52.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':react-native-webrtc:compileDebugJavaWithJavac'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

I have tried solution from My React Native was working fine upto 4 November but now throwing an exception while Running yarn android but no luck. Any help will be appreciated.

I have "react-native": "^0.66.3", "react-native-webrtc": "^1.94.1"

I tried below solution as well

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 {
            // Remove this override in 0.65+, as a proper fix is included in react-native itself.
            force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
        }
    }

@srahul9134
Copy link

srahul9134 commented Nov 10, 2022

Replace this in android/build.gradle file

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

       // ... your repository definitions

    }
}

@fusandy
Copy link

fusandy commented Nov 10, 2022

Hi, after applying the fix the build in eas works correctly, but when running the application in production in android it crashes at startup. Does it happen to anyone else? any solution?

+1.

in my case after digging around, it was looking for hermes.so file (which I don't use, disabled in the gradle file, and remove it after the build is done). And I still don't know how to fix it.

--------- beginning of crash
2022-11-06 11:39:26.214 8631-8696/*** E/AndroidRuntime: FATAL EXCEPTION: create_react_context
    Process: ***, PID: 8631
    java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
    	SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/***/lib-main flags = 1]
    	SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/~~-dS-qsYgLMRevGULTgeUdA==/***-ScQbcqeVLMVx2AtUh_jKrQ==/lib/x86 flags = 0]
    	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /vendor/lib flags = 2]
    	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /system/lib flags = 2]
    	Native lib dir: /data/app/~~-dS-qsYgLMRevGULTgeUdA==/***-ScQbcqeVLMVx2AtUh_jKrQ==/lib/x86
     result: 0
        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:918)
        at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:740)
        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:654)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:634)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:582)
        at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:20)
        at com.facebook.hermes.reactexecutor.HermesExecutorFactory.create(HermesExecutorFactory.java:29)
        at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:1054)
        at java.lang.Thread.run(Thread.java:923)

same here! upgrade version from 0.66.4 to 0.66.5, build successfully but can't run on the emulator and real device with below errors.

SoLoader.java:918 · com.facebook.soloader.SoLoader.doLoadLibraryBySoName
SoLoader.java:740 · com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl
SoLoader.java:654 · com.facebook.soloader.SoLoader.loadLibraryBySoName
SoLoader.java:634 · com.facebook.soloader.SoLoader.loadLibrary
SoLoader.java:582 · com.facebook.soloader.SoLoader.loadLibrary

@flyskywhy
Copy link
Contributor

Hi, after applying the fix the build in eas works correctly, but when running the application in production in android it crashes at startup. Does it happen to anyone else? any solution?

+1.
in my case after digging around, it was looking for hermes.so file (which I don't use, disabled in the gradle file, and remove it after the build is done). And I still don't know how to fix it.

--------- beginning of crash
2022-11-06 11:39:26.214 8631-8696/*** E/AndroidRuntime: FATAL EXCEPTION: create_react_context
    Process: ***, PID: 8631
    java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
    	SoSource 0: com.facebook.soloader.ApkSoSource[root = /data/data/***/lib-main flags = 1]
    	SoSource 1: com.facebook.soloader.DirectorySoSource[root = /data/app/~~-dS-qsYgLMRevGULTgeUdA==/***-ScQbcqeVLMVx2AtUh_jKrQ==/lib/x86 flags = 0]
    	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /vendor/lib flags = 2]
    	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /system/lib flags = 2]
    	Native lib dir: /data/app/~~-dS-qsYgLMRevGULTgeUdA==/***-ScQbcqeVLMVx2AtUh_jKrQ==/lib/x86
     result: 0
        at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:918)
        at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:740)
        at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:654)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:634)
        at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:582)
        at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:20)
        at com.facebook.hermes.reactexecutor.HermesExecutorFactory.create(HermesExecutorFactory.java:29)
        at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:1054)
        at java.lang.Thread.run(Thread.java:923)

same here! upgrade version from 0.66.4 to 0.66.5, build successfully but can't run on the emulator and real device with below errors.

SoLoader.java:918 · com.facebook.soloader.SoLoader.doLoadLibraryBySoName
SoLoader.java:740 · com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl
SoLoader.java:654 · com.facebook.soloader.SoLoader.loadLibraryBySoName
SoLoader.java:634 · com.facebook.soloader.SoLoader.loadLibrary
SoLoader.java:582 · com.facebook.soloader.SoLoader.loadLibrary

try --rerun-tasks e.g. ./android/gradlew assembleDebug --rerun-tasks -p ./android/

@Dinushka-Rukshan-FINAP
Copy link

After using the fix,,,,The error dissapeared but when I build a release App, the build's succesful but it keeps crashing as soon as it is getting installed. Is there a solution for that please ?

I'm also facing the same issue since yesterday. My React-native version was 0.70.3. Therefore I have updated that into RN 0.70.5 according to this patch. Now it's build succeeded but crashing as soon as it is getting installed. Did you resolved this issue.?

@srahul9134
Copy link

@Dinushka-Rukshan-FINAP Can you please try to use "react-native-reanimated": "^1.13.4", version?

@codeforpasssion
Copy link

after upgrading react native from 0.63.4. to 0.63.5 the app center build is failing
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.

@Dinushka-Rukshan-FINAP
Copy link

@Dinushka-Rukshan-FINAP Can you please try to use "react-native-reanimated": "^1.13.4", version?

@srahul9134 I have not used above package in my App. Should I installed that.?

@Sandeep-thapan
Copy link

Thanks Alot RN team Finally my project is working i use this code

   configurations.all {
       resolutionStrategy {
           // Remove this override in 0.65+, as a proper fix is included in react-native itself.
           force "com.facebook.react:react-native:" + "0.67.3"
       }
    }

@Rache-lBronfman
Copy link

Hey, I'm having some issues when upgrading from react-native v0.64.1 -> v0.64.4. This is the error message I am getting when trying to create a build or running ./gradlew clean in the android directory. Gradle version 7.0.2. Any help is appreciated.

**************************

FAILURE: Build failed with an exception.

* Where:
Script '~/node_modules/react-native/react.gradle' line: 360

* What went wrong:
A problem occurred evaluating script.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

Facing the same issue. updating from 0.64.2 to 0.64.4 and running ./gradlew clean yields this error

1: Task failed with an exception.
-----------
* Where:
Script '~/node_modules/react-native/react.gradle' line: 360

* What went wrong:
A problem occurred evaluating script.
> Cannot run Project.afterEvaluate(Closure) when the project is already evaluated.

gradlew version = 7.0.2

I'm also facing the same issue, @jhusdero did you find any solution?
all the solutions I found here didn't help me,
using react native 0.64.2, gradlew 7.0.2

@jhusdero
Copy link

@Rache-lBronfman no solution yet unfortunately. Still waiting for anyone to see if they have any solutions as its a little bit frustrating at the moment. 😩

@cipolleschi
Copy link
Contributor

cipolleschi commented Nov 10, 2022

Hi everyone! After the outage on the 4th of November, we mitigated and solved the problem in two ways:

  1. Releasing a batch of patch releases for versions 0.63 -> 0.70 to help everyone mitigate the issue.
  2. Reaching out to SonaType, who maintains Maven Central, to ask whether they can remove the offending artifacts.

This second measure would, effectively, solve the problem for everyone: when looking for a new version of React Native, Android won't find anything new on Maven and it will resolve to use the most recent version it has in the node_modules folder.
This is the same behaviour React Native had before the release of v0.71.0-rc.0.

On Tuesday, SonaType proceeded removing the artifacts for Android from their repository.
We waited at least 24h before writing this, to let the Gradle caches expire. At the moment of writing, the problem should be completely solved, therefore we are closing and locking this issue.
We noticed that a lot of people are reporting issues that are actually unrelated from this specific problem: for all of them, we encourage you to open a dedicated issue for your specific problem.

As a side effect of removing the artifacts, the automations of version 0.71.0-rc.0 are now broken. We shared instruction to use and test this release candidate (if you want to try it out) in the release page.

On a closing note, we noticed that many apps are still using old versions of React Native. We have a well-defined support policy that states that the only versions supported at the moment are 0.68, 0.69 and 0.70. As soon as 0.71 will be released as stable, 0.68 will go out of support.
We encourage everyone who is still on older versions of React Native to migrate to a supported version.

We hope that our approach to firefighting this outage has resolved the issues and you are able to once again develop your projects successfully - we will be sharing a report and our learnings in a postmortem blogpost before the end of the year.

@facebook facebook locked as resolved and limited conversation to collaborators Nov 10, 2022
MelroyNoronha added a commit to MelroyNoronha/radioPool that referenced this issue Nov 11, 2022
jorgtz added a commit to theticketfairy/tf-checkout-react-native that referenced this issue Nov 14, 2022
jeff66ruan added a commit to jeff66ruan/reagent-react-native that referenced this issue Nov 18, 2022
@kelset kelset unpinned this issue Dec 7, 2022
luca992 added a commit to luca992/keplr-wallet that referenced this issue May 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Platform: Android Android applications. Resolution: Fixed A PR that fixes this issue has been merged. RN Team
Projects
None yet
Development

Successfully merging a pull request may close this issue.