IssueTracker

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.

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.

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?

The preview URL has been updated with the fix.

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

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.

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.

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.

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

I have one device that was running canary previously, this device is no longer having the issue. I tried to use a published SMR to get debug info and confirm the loaded resource but I can't seem to get the remote debug console to work on this device, a first gen Chromecast. The console is working properly when connected to a V3 device but this one isn't running canary. If there's info I can provide or a way to validate if it's running canary please let me know.

Joris should be able to validate with a canary device that can debug for final confirmation tomorrow.

Are you able to connect via adb connect? If so, after connecting you can use adb logcat to get logs, and then you should be able to see the receiver version in the logs. Also see https://stackoverflow.com/questions/39481241/chromecast-debug for some other troubleshooting tips. (My guess is you've already tried both of these, but if not, maybe one of them will help.)

Terrific -- thanks for verifying!

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Koala Feature Drop | 2024.1.2 RC 1
• Android Gradle Plugin 8.6.0-rc01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

The fixes for this issue are now also available in:

• Android Studio Koala | 2024.1.1 Patch 2
• Android Gradle Plugin 8.5.2

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Hello, i encounter with similar issue in AGP 8.7.3 and R8 8.7.18:

    goto :goto_5b

    :cond_59
    move-object/from16 v15, p24

    :goto_5b
    const/high16 v16, 0x4000000

    and-int v0, v0, v16

    if-eqz v0, :cond_64

    const/16 v8, 0x0

    goto :goto_67

    :cond_64
    move-object/16 v264, p25
    ...
    move-object/from16 v2, v264

java.lang.VerifyError: Verifier rejected class:[0x430] copy1 v2<-v264 type=Undefined cat=3 

Re: comment#24: Please open a new issue at http://issuetracker.google.com/issues/new?component=317603.

In order to diagnose this issue, we would likely need a reproduction. If it would be possible for you to share a compiler dump, which contains the inputs to the D8 compilation, that should allow us to reproduce the issue. You can share this privately with christofferqa@google.com.

You can generate such a dump by running ./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/dumps.