Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[ANDROID] react-native-webview:compileDebugJavaWithJavac BUILD ERROR on 10.2.1

See original GitHub issue

Bug description: Hello, just upgraded to 10.2.1 from 9.4.

I am getting following two errors when building android.

.../node_modules/react-native-webview/android/src/main/java/com/reactnativecommunity/webview/RNCWebViewManager.java:1239: error: method setWebChromeClient(WebChromeClient) is already defined in class RNCWebView
    public void setWebChromeClient(WebChromeClient client) {
                ^


.../node_modules/react-native-webview/android/src/main/java/com/reactnativecommunity/webview/RNCWebViewModule.java:276: error: cannot find symbol
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
                                                    ^
  symbol:   variable Q
  location: class VERSION_CODES

I have done ./gradlew clean and reset npm cache, but same result.

Environment:

OS: MacOS
OS version: 10.15.5
react-native version: 0.61.5
react-native-webview version: 10.2.1

Issue Analytics

State:
Created 3 years ago
Reactions:17
Comments:21 (2 by maintainers)

Top GitHub Comments

22reactions

catmans1commented, Jun 4, 2020

My solution is change compile SDK target 29 in path android/build.gradle

ext {
        buildToolsVersion = "28.0.3"
        minSdkVersion = 16
        compileSdkVersion = 29 // change from 28 -> 29
        targetSdkVersion = 29 // change from 28 -> 29
    }

22reactions

mikehardycommented, May 30, 2020

@Jncls you must change your project to at least compile SDK target 29, usually it’s in the ext block of android/build.gradle

it brings in the new symbols but crucially will not alter how the platform or Google view your app for review or execution purposes so it is not a major change (as opposed to changing your target SDK - that needs careful consideration)

This was a breaking change for library consumers and was regrettably not marked as such, sorry for the trouble