IssueTracker

Thanks for the report, this issue is likely due to the Room Gradle Plugin changes that try to also configure the android test app asset directory to include the schemas so the MigrationTestHelper can pick them up. I'll try to work on a fix soon.

Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <danysantiago@google.com>
Link:      https://android-review.googlesource.com/3391005

Configure the schema asset android copy task within its register block and not within AGP's wiredWith lambda.

Configure the schema asset android copy task within its register block and not within AGP's wiredWith lambda. 
 
Otherwise the tasks inputs are locked by the time the wiredWith lambda passed to addGeneratedSourceDirector() is invoked and will lead to "property 'inputDirectory' is final and cannot be changed any further". 
 
Bug: 376071291 
Test: Manual with sample repro app 
Change-Id: I2c9da4855cd31d7df3276424546aba4c53edf7ea

Unfortunately the fix did not make it to the alpha12 release, but it will indeed be in the next release.

When will this be released? It's more than a month now?

Sorry for the delay - Next androidx release is January 29

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.room:room-gradle-plugin:2.7.0-alpha13

Pulling off BugJuggler so we can discuss this in weekly meeting.

Looking into whether this is really blocked on b/111253910.

Detected these failing tasks: [':annotation:annotation:compileKotlinJvm']
> Task :annotation:annotation:compileKotlinJvm
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/Px.kt:28:1 This annotation is not applicable to target 'annotation class'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresApi.kt:52:5 This annotation is not applicable to target 'value parameter'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresApi.kt:54:5 This annotation is not applicable to target 'value parameter'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresExtension.kt:64:5 This annotation is not applicable to target 'value parameter'
e: file://$SUPPORT/annotation/annotation/src/jvmMain/kotlin/androidx/annotation/RequiresExtension.kt:66:5 This annotation is not applicable to target 'value parameter'

And we're immediately hit by this ourselves.

public annotation class RequiresApi(
    /**
     * The API level to require. Alias for [.api] which allows you to leave out the `api=` part.
     */
    @IntRange(from = 1) val value: Int = 1,
    /** The API level to require  */
    @IntRange(from = 1) val api: Int = 1
)

The annotation needs to be moved next to Int. This would be highly disruptive for clients.

Maybe we don't?

Or, at the very least, maybe we add TYPE_USE but don't remove the targets?

Please don't add type use to these annotations without also updating the lint analysis to support/check on types.

without also updating the lint analysis to support/check on types.

Lint team would need to do that, but I'm happy to provide motivation. We have a parallel bug for Metalava that my team would be handling.

Or, at the very least, maybe we add TYPE_USE but don't remove the targets?

We could consider adding TYPE_USE, implementing a lint check with auto-fix to migrate, and effectively "deprecating" the other targets. It would still be extremely disruptive, though. And we'd be on the hook for migrating google3, which would be somewhere between difficult and impossible.

Lint team would need to do that, but I'm happy to provide motivation. We have a parallel bug for Metalava that my team would be handling.

Right -- just making it clear that this isn't currently in the plans from the lint team, so let's not update the public annotations with type use and then leaving tools support as TODO, since the primary purpose of these annotations is enforcement.

Putting this on the backburner again. There are still some big questions around whether this is a good idea given the trade-offs around (1) disrupting clients and (2) ownership in g3.

We have an owner and time scheduled for the blocking issue, so this is likely to make progress in Q3.

Right -- just making it clear that this isn't currently in the plans from the lint team, so let's not update the public annotations with type use and then leaving tools support as TODO, since the primary purpose of these annotations is enforcement.

Unclear what we'll do about lint, though. Tor, I'm finding a couple of bugs filed against Lint public component that touch on type annotations but nothing that's obviously "implement support for TYPE." Is there an existing bug that I can use as blocking, or do you want a new one?

Related with

• b/209843426
• https://youtrack.jetbrains.com/issue/KT-48900
• https://youtrack.jetbrains.com/issue/KT-67981

Since Kotlin 1.6, kotlin compiler warns when use androidx.annotation in Container types. Also, Since kotlin 2.0, kotlin compiler warning cannot be suppressed and it looks that Kotlin compiler team will not provide workaround to suppress.