Fixed
Status Update
No update yet.
Comments
fa...@gmail.com
This looks like a regression from AGP 3.4 to AGP 3.5. Ian, can you have a first look?
ct...@chromium.org
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.
fa...@gmail.com
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.
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.
fa...@gmail.com
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.
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.
ct...@chromium.org
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
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
ct...@chromium.org
ct...@chromium.org
Continuing my last comment:
Also I've noticed that uploading libraryB to a Nexus Server instead of using AAR as a module works properly
Also I've noticed that uploading libraryB to a Nexus Server instead of using AAR as a module works properly
st...@chromium.org
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 :)
Also, this is not exactly the same issue as the original reporter reported, but I hope my answer helps :)
ct...@chromium.org
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.
pe...@google.com
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, 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)
pe...@google.com
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!
el...@google.com
st...@chromium.org
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.
el...@google.com
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.
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.
st...@chromium.org
ap...@google.com
Great! Thank you for the update on this.
st...@chromium.org
sp...@google.com
I'm afraid this is not solved yet. Before my last comment (https://issuetracker.google.com/issues/140508065#comment6 ) I've tested it on Android Studio Canary with 3.6.0-alpha10, and I took the same error.
am...@chromium.org
That is a subtly different issue, as you are not embedding the AAR. In general please file separate issues.
Your issue is that you've lost the dependency information by importing the aar as a subproject. I wish we didn't have a template for that as it leads to issues like this.
The way to solve your issue is to publish the AAR to e.g. a local maven repository so the dependency information is preserved and everything will work.
Your issue is that you've lost the dependency information by importing the aar as a subproject. I wish we didn't have a template for that as it leads to issues like this.
The way to solve your issue is to publish the AAR to e.g. a local maven repository so the dependency information is preserved and everything will work.
pe...@google.com
Any update on this? This still isn't resolved in 3.5.1 and I'm stuck on the older version still. Several people in this thread have the same issue and are waiting for this to be resolved.
https://github.com/twilio/video-quickstart-android/issues/430
Description
SUMMARY
The Permission prompt can be obscured by a Picture-in-Picture (PiP) window for video or documents, potentially allowing a page to obtain permissions without user awareness.
Current address bar permission prompts do check for PiP window occlusion. This issue is very similar to
To minimize user interaction, a compromised renderer can open the PiP window, as seen in
VULNERABILITY DETAILS
A page can display a Video or Document PiP window over a normal window with a permission prompt, obscuring the prompt and unknowingly allowing it when the user interacts with the webpage.
An attacker can instruct the user to press keys while the permission prompt is obscured. For example, pressing Tab three times followed by Enter twice can result in the user granting permissions without their awareness.
VERSION
REPRODUCTION CASE
Note: The Proof of Concept (PoC) uses Document PiP, but this also works with Video PiP.
Prerequisites: None required.
poc.htmlandpermission.htmlfiles.poc.htmldirectly from the same folder.Observed: The attacker can obtain permissions without the user’s awareness.
Expected: The attacker should not be able to obtain permissions without the user’s awareness.
CREDIT INFORMATION
Reporter credit: Shaheen Fazim