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!

We are currently using the old AndroidSourceSet APIs to configure Checkstyle and Detekt for Android projects, as described in this issue: https://issuetracker.google.com/issues/170650362

As far as I can tell, this is not yet covered by the new APIs and this would likely apply to other static analysis tools that need to process source files as well.

I created a new ticket talking about this AndroidSourceSet use case here: https://issuetracker.google.com/issues/263876380

My project currently uses the javaCompileProvider and preBuildProvider APIs of the BaseVariant class.

Fir the javaCompileProvider case, we use this mainly in Application projects. We have some custom code generation tasks that we run that require the classpath of the application be available (so we use the output of the task), and that we want to be done "at the same time" before tasks that depend on JavaCompile complete have the code we generate ready as well. Example usage is:

android.applicationVariants.configureEach { variant ->
  val customTaskOne = project.tasks.register("customTaskOne${variant.name.capitalized()") {
    dependsOn(variant.javaCompileProvider, kotlinCompileTask)
  }

  val javaCompileOutput = variant.javaCompileProvider.get().destinationDirectory.get().asFile
  val codeGenerationAction = CodeGenAction(javaCompileOutput, variant)

  variant.javaCompileProvider.configure {
    finalizedBy(customTaskOne)
    doLast(codeGenerationAction)
  }
}

I understand this is a bit janky, but I'm looking to update the code and make sure we're doing things "The Right Way(tm)" going forward. If there's a similar way to accomplish what we're looking for, I'd love to know about it, especially if it's a tool or technique that I'm not familiar with.

For the preBuildProvider usecase, we're essentially generating some code early on in the process that just needs to be ready. I can likely use some other method of having this task run (as it doesn't really depend on anything else other than being done before the APK is packaged). What would be the suggested way with the new gradle-api classes to perform this sort of work?

EDIT: I've spent the last few days looking through the Android Plugin Cookbook and found some stuff that looks like it's close to working, but doesn't quite let me solve the problem I'm trying to solve. To summarize the above, I have a set of tasks that I use to essentially scan the classpath and identify classes tagged with certain things (Annotations, Interfaces) and then generate either a new .class file for inclusion in the dex or generate a JSON file for inclusion in the application's assets.

For reference, all of this is with AGP 7.4.

I tried using the same task for both to see if AGP would know how to handle that:

                variant.artifacts
                    .forScope(ScopedArtifacts.Scope.ALL)
                    .use(scannerTask)
                    .toAppend(
                        ScopedArtifact.CLASSES,
                        ScannerTask::output
                    )

                variant.artifacts.forScope(ScopedArtifacts.Scope.ALL)
                    .use(scannerTask)
                    .toGet(ScopedArtifact.CLASSES,
                        ScannerTask::allJars,
                        ScannerTask::allDirectories)

but that led to things just not executing. I didn't see anything with the task name in the --debug output. So, I went ahead and tried using two tasks: one for toGet that would scan all the input and generate the .class file, and one that would then take that output of that scan task and then add it using toAppend. Attempting to do this led to a circular dependency, leading me to believe that toGet is ALWAYS executed last.

So, I went ahead and tried using toTransform:

variant.artifacts.forScope(ScopedArtifacts.Scope.ALL)
            .use(scannerTask)
            .toTransform(
                ScopedArtifact.CLASSES,
                ScannerTask::allJars,
                ScannerTask::allDirectories,
                ScannerTask::output
            )

And that worked! The class was generated, and included in the dex file. The problem was that the API was expecting me to essentially touch every input file and then add them to the output. That sounds like it's going to kill my build times.

Am I on the right track here and maybe just missing an API to use? Or is this use case not supported by the current APIs?

You are correct, the toTransform is the only API you can use in your case because you are trying to get the final version of the artifact in your scannerTask while also trying to append (from the same Task). Even if you used 2 tasks, you would end up in a circular dependency.

You are also correct this is not going to be great for your build time.

One of the way I can think of would be to make a new version of toTransform that would be a lot smarter and allow you to tag unchanged jars/directories. I think that would solve your case completely ?

But in the meantime, maybe using a KSP or plain old annotation processor might be another solution, not exactly sure about your constraints.

I'm sure I could get that to work, having a sort of incremental toTransform, though I don't think that would be the ideal solution for my particular use case. My attempt to use toTransform was based off it allowing me to essentially take a look at every class that's going to end up in the package. I'm not looking to actually modify any of the classes that I scan. With the API you suggested, we would essentially be marking everything we look at as "unchanged", and then attempting to add a new class/asset based on what we saw, or perhaps modifying one or two classes/assets by adding the results of our scans.

My end goal is to essentially "append" to the output using everything previously built as an input. So, maybe not "append", but almost "finalize". That's why we currently use the finalizedBy and doLast APIs for the JavaCompile task. I think my big concern would be using the "transform" API in a way that isn't strictly "transforming". If that's not one that you share, then this certainly would be worth trying out.

But in the meantime, maybe using a KSP or plain old annotation processor might be another solution, not exactly sure about your constraints.

That's certainly one of the avenues I'm investigating. I'm just trying to make sure I've taken a look at and understand all of the options that are available.

The problem of a finalize API is that only one thing can do it. If we expose this as a proper API, then we have to make sure only 1 plugin can do it and fail if 2 plugins try to do it. If we start having several published plugins using that APIs, they will not be compatible with each other.

This is really not a path we want to go down at the moment.

So "transforming" but not actually touching the files is perfectly fine (as long as you do copy them into the output), though you have to realize that the API cannot guarantee that you are last. You have to manage your plugin application order and hope your transform is added last.

The problem of a finalize API is that only one thing can do it. If we expose this as a proper API, then we have to make sure only 1 plugin can do it and fail if 2 plugins try to do it. If we start having several published plugins using that APIs, they will not be compatible with each other.

Oh yeah, I absolutely understand the turmoil adding an API like that can cause, especially down the line. I don't blame you at all for not wanting to codify that potential nightmare in the public API. If the "transform" API is built and maintained in such a way that it accounts for folks not always actually wanting to transform classes, I think that would be sufficient.

you have to realize that the API cannot guarantee that you are last.

That's okay. No external dependencies should be using these, as they're strictly internal. We also don't need to worry about other internal plugins using/generating classes that we would be required to scan. We don't need to be "last" as much as we need to be "after compilation but before packaging", which this API would provide us.

I have been thinking about this a bit more and it's actually not easy to provide an API where you can identify some untouched inputs as outputs.

The main reason is that Gradle will complain if 2 tasks output the same file/directory, so one way of another, we must copy the inputs into outputs which is probably what you already do. At least we would save the merging step which is an improvement but there would still be a fair amount of I/O.

Would it be possible to have a "Read Only" API that allows scanning/reading of the non-generated code for the project which would be followed by tasks that perform this code generation/modification? Something like

variant.artifacts
       .forScope(ScopedArtifacts.Scope.ALL)
       .scan(scannerTask)
       .andOutput(writeTask)
       .with(
           ScopedArtifact.CLASSES,
           ScannerTask::allJars,
           ScannerTask::allDirectories,
           WriteTask::output
        )
    

So, my scannerTask would be responsible for running over the classes, and building up the manifest that it wants to generate. Then, the writeTask would take that manifest and generate code to the output directory. This way you have a very clear set of processing at output tasks. On my side, I could keep the manifest in memory, since I expect the tasks to be run in a pair (as in, writeTask wouldn't run if scannerTask hasn't). If it's better practice, scannerTask can be used as an input for writeTask.

I can see the scan API being useful for any sort of processing on the APK that needs to be done, including any sort of reporting folks might want. It can allow classes to be scanned, but not necessarily modify the output. However, if andOutput were included, the writeTask would be added alongside the other code modifying tasks. I think the order here can make sense if the scannerTask were always to operate on the non-generated, non-modified classes.

I'm not sure if that all makes sense as I'm spitballing.

you are still introducing a circular reference, as the Scanner Task wants to have access to all the final CLASSES and generate a manifest that the WriterTask would use to generate a new element of the CLASSES artifact. The fundamental issues here are :

• provide an API that allows to transform but mostly leaving original items unchanged.
• be independent of the Plugin apply order.

mostly something like :

variant.artifacts.forScope(ScopedArtifacts.Scope.ALL) .use(scannerTask) .toGetAndAdd( ScopedArtifact.CLASSES, ScannerTask::allJars, ScannerTask::allDirectories, ScannerTask::output )

but that means you are not guaranteed to have the final version of CLASSES as some other Plugin may add a folder after you...

That's why I was trying to phrase it as "non-generated", but I'm not sure how useful that would be outside of my specific use case (and obviously nobody wants to support an API for some weird one-off). For our project, what other plugins might do work after we perform ours doesn't matter, as I can guarantee for my project, in this instance, that things will behave as I expect.

If this is something you think might be worthwhile to add, with the above caveats, that would be swell. We'll likely use it in some form. If it's not something that seems like it would be worth supporting, which is not unreasonable, I'm sure I'll figure out some other solution before the time comes to migrate. Necessity is the mother of invention, after all.

I appreciate the discussion and consideration.

Hi,

I wrote a plugin that generates a wrapper around string resources, so I had a mockable class while still being able to use string resources in viewModels etc.

The way I did this before was to add a dependency on the process<...>Resources task, find the R.jar file, unzip and use a class visitor to extract the string/plural names. Then use codegen to create the wrapper with this data. Then I had to add my task as a dependency on compile<...>Kotlin.

It's taken me a while to get to grips with the new system, just trying to slot my task to run at the correct time, but I've ended up with something like the following:

project.plugins.withType(AppPlugin::class.java) {
    val androidComponents = project.extensions.getByType(AndroidComponentsExtension::class.java)
    androidComponents.onVariants { variant ->

        variant.sources.java?.let { sources ->
            val generateStringsTask = project.tasks.register(
                "generate${variant.name}Strings",
                GenerateVariantStringsTask::class.java,
            ) {
                it.variantPackageName.set(variant.namespace)
                it.outputDir.set(project.layout.buildDirectory.dir("generated/source/stringrepository/${variant.name}"))
            }

            variant.artifacts
                .use(generateStringsTask)
                .wiredWith(GenerateVariantStringsTask::symbolsFile)
                .toListenTo(SingleArtifact.RUNTIME_SYMBOL_LIST)

            sources.addGeneratedSourceDirectory(
                generateStringsTask,
                GenerateVariantStringsTask::outputDir
            )
        }
    }
}

I'll admit, this new way is a hell of a lot easier to get the data I need, The problem is that the amount of exposed artifacts is pretty limited (at least compared to what I've seen for InternalArtifactType).

RUNTIME_SYMBOL_LIST includes transitive dependencies, breaking my generated code as the module's R class can no longer 'see' those transitive resources (with the default APG 8+ non transitive R class setting).

Ideally having a non-transitive version of that artifact (to the local_only_symbol_list file?) would be perfect, but considering my confusing on picking up these new APIs there's a good chance i'm wrong on approach for this.

Any guidance would be very much appreciated.

Thanks

#36, I filed Issue 360117673 to track this

Thank you for the great work you do keep it up please.