DexingNoClasspathTransform (minSdk >= 24) with Java 11 target fails due to missing nest members [266599585]

Fixed

Bug

Status Update

No update yet.

Description

hu...@google.com

created issue #1

Jan 24, 2023 08:17PM

(I'm creating this bug based on Internal Issue 234414461.)

Steps to reproduce

In app, set minSdk >= 24 (when minSdk < 24, dexing transforms are not incremental)
In lib, set compileOption.targetCompatibility = "11" (in lower Java versions, nest members do not exist)
In lib, write a Java class with nested classes
Copy this project to another location. Run ./gradlew :app:mergeLibDexDebug --build-cache at that location.
Come back to the current project, run ./gradlew :app:mergeLibDexDebug --build-cache. Many tasks/transforms should have cache hits.
Make a change to the Java class above or its nested classes.
Run ./gradlew :app:mergeLibDexDebug --build-cache again. It will fail with:

* What went wrong:
Execution failed for task ':app:mergeLibDexDebug'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Failed to transform debug (project :lib) to match attributes {artifactType=android-dex, asm-transformed-variant=NONE, com.android.build.api.attributes.AgpVersionAttr=8.1.0-dev, com.android.build.api.attributes.BuildTypeAttr=debug, com.android.build.gradle.internal.attributes.VariantAttr=debug, dexing-enable-desugaring=true, dexing-enable-jacoco-instrumentation=false, dexing-is-debuggable=true, dexing-min-sdk=24, org.gradle.category=library, org.gradle.jvm.environment=android, org.gradle.libraryelements=classes, org.gradle.usage=java-runtime, org.jetbrains.kotlin.platform.type=androidJvm}.
      > Execution failed for DexingNoClasspathTransform: MyApplication/lib/build/intermediates/runtime_library_classes_dir/debug.
         > Error while dexing.
...
Caused by: com.android.builder.dexing.DexArchiveBuilderException: Error while dexing.
        at com.android.builder.dexing.D8DexArchiveBuilder.getExceptionToRethrow(D8DexArchiveBuilder.java:186)
        at com.android.builder.dexing.D8DexArchiveBuilder.convert(D8DexArchiveBuilder.java:125)
        at com.android.build.gradle.internal.dependency.BaseDexingTransform.process(DexingTransform.kt:316)
        at com.android.build.gradle.internal.dependency.BaseDexingTransform.processIncrementally(DexingTransform.kt:227)
        at com.android.build.gradle.internal.dependency.BaseDexingTransform.doTransform(DexingTransform.kt:137)
        at com.android.build.gradle.internal.dependency.BaseDexingTransform.transform(DexingTransform.kt:107)
...
Caused by: com.android.tools.r8.CompilationFailedException: Compilation failed to complete, origin: MyApplication/lib/build/intermediates/runtime_library_classes_dir/debug/com/example/lib/JavaClass.class
        at Version.fakeStackEntry(Version_8.1.8-dev.java:0)
...
        at com.android.builder.dexing.D8DexArchiveBuilder.convert(D8DexArchiveBuilder.java:123)
        ... 125 more
Caused by: com.android.tools.r8.utils.b: Compilation of classes com.example.lib.JavaClass requires its nest mates com.example.lib.JavaClass$NestedClass (unavailable) to be on program or class path.
...

Root cause

Dexing transforms use a desugaring graph to store dependencies among class files for incremental dexing/desugaring.

The desugaring graph's nodes are currently absolute paths, which means after a remote cache hit, it will not be usable and will result in subsequent failed incremental builds.

We were aware of this issue when designing the graph and used a workaround, but (I think) at some point Gradle changed the behavior and it no longer worked.

Potential fix

Make the desugaring graph relocatable. It is a bit difficult because there isn't one single root path to normalize the absolute file paths (instead, there are multiple root paths).

(If we can't work out a solution soon, the temporary measure is to ensure in the first build after a remote cache hit, affected transforms will be non-incremental.)

Comments

sh...@gmail.com <sh...@gmail.com> #2Mar 10, 2023 04:45PM

Comment has been deleted.

Message last modified on Mar 10, 2023 04:45PM

sh...@pinterest.com <sh...@pinterest.com> #3Mar 10, 2023 04:46PM

I'm having this issue with 1 of my 3 Chromecasts and actually bought a new Chromecast because I thought it was broken.

hu...@google.com <hu...@google.com> #4Mar 10, 2023 06:40PM

Hi There,

I am also experiencing this issue. I have 9 chromecasts V3, all bought at the same time and on 2 of them I was not able to cast images using either the
default or styled media reciever.
When comparing the debugs of a working and non working device I found that the non working one is using the canary framework instead of the V3

First of all i checked and this device doesn't have the Preview program on, how come it gets beta code ?

The error is as stated above on the cast.o.media.Il.create function

Non working canary
c = c.startsWith("image/") ? cast.o.media.Il.create(b) : .L(new hu(b,ku))

Working V3
c = c.startsWith("image/") ? .K(new ot(b)) : _.K(new Nt(b,Qt))

sh...@pinterest.com <sh...@pinterest.com> #5Mar 10, 2023 08:39PM

Thanks for reporting the issue. We will investigate further and get back to you with our findings.

hu...@google.com <hu...@google.com> #6Mar 13, 2023 05:02PM

Thanks for reporting the issue. We will investigate further and get back to you with our findings.

Can you also confirm whether this is happening with our latest version? You can try the preview URL that can be found here:

https://developers.google.com/cast/preview-url

as...@gmail.com <as...@gmail.com> #7Mar 15, 2023 05:23PM

Hello,

So I created a custom reciever app pointing to the preview cast reciever version and I have the same error

https://www.gstatic.com/cast/sdk/libs/caf_receiver/preview/cast_receiver_framework.js
It looks like the bug is also present in the preview version.

The problem I have is even if I specify to use the v3 cast reciever (

https://www.gstatic.com/cast/sdk/libs/caf_receiver/v3/cast_receiver_framework.js) in my custom reciver app in the debbugs is see the chromecast using the canary library (

https://www.gstatic.com/cast/sdk/libs/caf_receiver/canary/cast_receiver_framework.js) ... Why?

Why this chromecast in particular has this behavior ?
serial number is: 1125ADSFDMJ

Is there another version of the cast_receiver_framework.js that i could use ?

Thanks,

hu...@google.com <hu...@google.com> #8Mar 17, 2023 05:47PM

Can you please confirm if this preview version is the same one announced on [Feb 10th (https://groups.google.com/g/cast-sdk-announcements/c/-dLdTPHTvDc) that is now in canary testing?

There are disconnects between the dates in the announcement channel and the release notes this year, alignment seems to be be better in Nov/Dec last year.

as...@gmail.com <as...@gmail.com> #9Mar 20, 2023 07:57AM

Hello,

The SDK version is CAST SDK CAF Version: 3.0.0095 the shaka player loaded is 3.0.10. So apparently not the same as the one announced on Feb 10th (3.0.8).
I attached the whole debug output with the preview framework (

https://www.gstatic.com/cast/sdk/libs/caf_receiver/preview/cast_receiver_framework.js)

How come some devices use canary and some do not ?

Thanks,

Joris

hu...@google.com <hu...@google.com> #10Mar 20, 2023 12:41PM

To answer your questions, as we roll out the releases, some devices will see the new release (canary) and others will see the old release until the new release is fully ramped up in production. In Feb we found an issue with Shaka player version 3.0.8 which was fixed in version 3.0.10. We delayed the rollout of the receiver release to get the updated Shaka player 3.0.10 into the release, and that's what's currently in canary (and in preview). (The preview URL will always point to the newest build about to be released.)

For the cssting photos bug reported here, engineering has implemented a fix, and we hope to update the release with the fix tomorrow. We'll do our best to update this bug as soon as the fix is in canary.

sh...@pinterest.com <sh...@pinterest.com> #11Mar 21, 2023 10:47PM

We're in the process of updating the preview URL with the fix, which should be in place in an hour or so. Joris or John, once that's in place, would you be able to do quick check against the preview URL with the development version of your apps to verify that this has fixed the problems reported?

Message last modified on Mar 22, 2023 08:18PM

hu...@google.com <hu...@google.com> #12Mar 22, 2023 01:19PM

The preview URL has been updated with the fix.

sh...@pinterest.com <sh...@pinterest.com> #13Mar 22, 2023 08:19PM

Hi, can you please confirm whether this issue is fixed or not with the latest Preview URL?

Thanks

hu...@google.com <hu...@google.com> #14Apr 6, 2023 10:55AM

Marked as fixed.

Hi,

I just tested it and it works now !!

Thanks a bunch for your quick response.
We'll do some more testing in the next few days. We'll let you if we encounter other issues.

Thanks,

Joris

as...@gmail.com <as...@gmail.com> #15Apr 11, 2023 12:45PM

Great -- thanks for the quick confirmation! We'll be rolling this fix out to production soon. (Full ramp will be early next week.)

hu...@google.com <hu...@google.com> #16Apr 11, 2023 01:42PM

I've tested and confirm that the issue is resolved in preview mode, also appreciate your rapid feedback.

As I'm new to building and support Chromecast based applications I'd like to better understand an aspect of the release and testing process.

Was the issue we experienced present in the preview release of Feb 1st or Feb 10th, or were unannounced updates to the preview version made after the fact.

What I want to understand is if we monitor preview releases and test our application regularly with them can we avoid this type of issue impacting us in the future? Based on our admittedly very limited sample of Chromecasts it looks like Canary was in use on 10-20% of devices before this issue was identified.

as...@gmail.com <as...@gmail.com> #17Apr 18, 2023 04:34PM

Thanks for testing, John! Yes, this issue has been present since the initial preview release was released in February. You should have been able to see this in the initial preview that was released back then. So going forward, testing with the preview URL prior to a new release will be the best way to ensure that you can catch issues affecting your app in advance of a new release.

Message last modified on Apr 18, 2023 04:35PM

an...@google.com <an...@google.com> #18Apr 18, 2024 09:05PM

Excellent, thanks for the confirmation. I wasn't working in this space back when the preview release came out. It's good to know that if we subscribe and monitor the cast SDK announcements we'll be able to detect issues early and ensure the ongoing functionality of our product.

Thanks again to you and all the team for the excellent support we've received on this issue.

hu...@google.com <hu...@google.com> #19Apr 19, 2024 10:16AM

We've updated the canary with the fix -- can you verify that you're now seeing that the problem is fixed?

Message last modified on Apr 19, 2024 10:17AM

ma...@gmail.com <ma...@gmail.com> #20Jun 22, 2024 04:09AM