IssueTracker

This looks like a regression from AGP 3.4 to AGP 3.5. Ian, can you have a first look?

Thank you very much for the reproduction project! It does indeed reproduce the issue locally. The issue appears to be the compiler failing to rewrite the invocation to a public static interface method to target the companion class created while desugaring interface methods. I'll follow up in this issue thread once more information is available and a fix is found.

Reassigning to Ivan as this is looking like a build issue and I'm not sure if the project configuration needs changing or there is an error in the build system.

Running:

  ./gradlew :quickstartKotlin:assembleDebug --info

yields output with:
<snip>/.gradle/caches/transforms-2/files-2.1/a4e476e9d975337caa4d7a965148dce1/video-android-4.2.0/jars/classes.jar: D8: Type `org.webrtc.EglBase` was not found, it is required for default or static interface methods desugaring of `void com.twilio.video.EglBaseProvider.<init>()`


More info:

The application has a dependency on com.twilio:video-android:4.2.0 and it appears to include a copy of webrtc somehow. Found it locally in .gradle/caches/transforms-2/files-2.1/HASH/video-android-4.2.0/jars/libs/libwebrtc.jar

The definition of type com.twilio.video.EglBaseProvider in video-android-4.2.0 has an <init> with a static invoke to EglBase::create.

The interface org.webrtc.EglBase is defined in libwebrtc.jar

Outside of gradle, putting libwebrtc.jar in the program path or the classpath when compiling with D8 and a min-api to desugar default interface methods, the call to EglBase::create is correctly rewritten to EglBase$-CC::create.

As a workaround you can add "android.enableDexingArtifactTransform.desugaring=false" to gradle.properties.

In Android Gradle Plugin 3.5 we started dexing and desugaring using Gradle artifact transforms. This allows us to use Gradle caching and parallelism. The way we set up desugaring classpath is by using dependencies information from the POM file. In this case, "video-android-4.2.0" packages libwebrtc.jar inside the AAR and we fail to add those files to desugaring classpath. D8 is unable to resolve types and to rewrite invocation to the generated companion class.

Note, I am facing the same issue in an app that uses a library, lets call it libraryB, that make use of webrtc but I don't include webrtc.jar in libraryB, as I use implementation configuration for libraryB. I then generates an AAR of it and import this AAR as a module to make use of it on final app. Therefore in app's build.gradle file I also import webrtc as implementation.

I have attached an android project so you can reproduce this case. webrtclibAAR module is an AAR file generated by running gradle assemble task on webrtclib module

Continuing my last comment:

Also I've noticed that uploading libraryB to a Nexus Server instead of using AAR as a module works properly

The issue is that we need AAR to have POM alongside to contain all dependency information. When just dropping an AAR to an output directory, this information is lost. However, when publishing to a Maven repo, this information exists.

Also, this is not exactly the same issue as the original reporter reported, but I hope my answer helps :)

Our team found a fix for this issue. We manage the video-android dependency and had to build that AAR with the latest Gradle plugin (3.5.0). Once we did that, it resolved the crash. Thank you for looking into this problem though.

Never mind, this is still an issue. We found a false positive in our testing that led us to believe building video-android with gradle plugin 3.5.0 resolved the crash. It is definitely related to storing the AAR to our artifact repository in Bintray. As a sanity check we referenced the AAR locally and it works fine.

Also, thank you for sharing the workaround above! We tested adding that line to the quickstartKotlin's gradle.properties file and it resolved the crash. We'll use this as a temporary solution in the meantime.

(Used a different email address here, sorry for the confusion)

Also, are there plans to resolve dependencies that are packaged outside of what's specified in a POM file within the AAR? Or would we need to ensure that a POM file is always present defining dependencies like libwebrtc.jar? Our team would like to know so we can either prioritize this work or wait for the next release of the Gradle plugin. Thanks!

We will handle jars packaged under libs directory in an AAR, so there is no need to add those in the POM file. cmw@ fixed that in 3.6 (he can add more details when it got fixed), so that should work, and there is no need to add e.g. libwebrtc.jar to the POM file.

I think this is fixed in 3.6.0-alpha05 by
https://android.googlesource.com/platform/tools/base/+/f7f446e6c304b035e347eccd181e2b6ee4b16d97#
which merges all of the the libs jars from the AAR into one jar rather than exporting all of them separately, meaning that the classes in an AAR are all desugared together.

Great! Thank you for the update on this.