Status Update
Comments
au...@google.com <au...@google.com> #2
Thanks for reporting this. We will investigate this and get back to you once we have an update.
da...@google.com <da...@google.com> #3
Branch: androidx-main
commit 5dd50789a7bbcba846f41e4265bd5411fb542b02
Author: Vighnesh Raut <vighnesh.raut13@gmail.com>
Date: Wed Dec 21 17:16:55 2022
Fixed "clickable" modifier doesn't work with ImmersiveList
* In the "focusableItem" modifier, we add a "focusable" modifier. Now, if the user adds the "clickable" modifier, the
"focusable" modifier added by us has no effect. So, we are now removing the "focusable" modifier
from it. Now, user will have to manually add "focusable()" or "clickable()" along with
"focusableItem". Since this is an immersive list item, ideally, the item will always be clickable.
* Renamed "focusableItem" modifier to "immersiveListItem" modifier which is a better name for the new API and also this
makes it clear, while reading, that this modifier is only part of "ImmersiveList" and also makes
doesn't hint that "focusable()" modifier would be auto-applied
* Moved the immersive list component out of the sub-package
* Added missing ktdocs for params
* Added sample immersive list usage
Bug:
Test: Updated tests
Relnote: "Renamed `focusableItem` to `immersiveListItem` and removed `focusable()` modifier. Now
users will have to manually add `focusable()` or `clickable()` modifier along with
`immersiveListItem`"
Change-Id: I1fd6c8cca3d7f4e810ad838ec1aad0b3c3e41450
M tv/integration-tests/demos/src/main/java/androidx/tv/integration/demos/ImmersiveList.kt
A tv/samples/src/main/java/androidx/tv/samples/ImmersiveListSamples.kt
M tv/tv-material/api/current.txt
M tv/tv-material/api/public_plus_experimental_current.txt
M tv/tv-material/api/restricted_current.txt
M tv/tv-material/src/androidTest/java/androidx/tv/material/ImmersiveListTest.kt
M tv/tv-material/src/main/java/androidx/tv/material/ImmersiveList.kt
au...@google.com <au...@google.com> #4
The issue has been fixed and merged to Android Open Source Project. The fix should be available in the next tv-compose release (Version: 1.0.0-alpha04).
Closing this ticket. Feel free to re-open in case of any issues.
Thanks 😀
da...@google.com <da...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.tv:tv-material:1.0.0-alpha04
da...@google.com <da...@google.com> #6
Looking at the Gradle metadata diff ("org.gradle.libraryelements": "jar"
? Should that be an aar
instead?
`
hm...@google.com <hm...@google.com> #7
yes, androidApiElements/runtimeElements variant publications should have aar value on the libraryelements attribute. What version of Gradle, AGP, KGP are you using in your library?
What's bizarre is that the compileClasspath is using the jvm vairant (in the test project you shared), it's only at runtime that it resolves the -android artifact of your library...
hm...@google.com <hm...@google.com> #8
It's very confusing, though why the android variant is chosen.
./gradlew dependencyInsight --configuration runtimeClasspath --dependency androidx.sqlite:sqlite:2.5.0-beta01
> Task :dependencyInsight
androidx.sqlite:sqlite:2.5.0-beta01
Variant androidRuntimeElements-published:
| Attribute Name | Provided | Requested |
|------------------------------------|--------------|--------------|
| org.gradle.status | release | |
| org.gradle.category | library | library |
| org.gradle.jvm.environment | android | standard-jvm |
| org.gradle.libraryelements | jar | jar |
| org.gradle.usage | java-runtime | java-runtime |
| org.jetbrains.kotlin.platform.type | jvm | jvm |
| org.gradle.dependency.bundling | | external |
| org.gradle.jvm.version | | 21 |
org.gradle.jvm.environment=standard-jvm is obviously requested and it doesn't match with the provided value for android. Looking at the jvmRuntimeElements from the diff you supplied of the gradle meta file, we see
{
"name": "jvmRuntimeElements-published",
"attributes": {
"org.gradle.category": "library",
"org.gradle.jvm.environment": "standard-jvm",
"org.gradle.usage": "java-runtime",
"org.jetbrains.kotlin.platform.type": "jvm"
},
"available-at": {
"url": "../../sqlite-jvm/2.5.0-beta01/sqlite-jvm-2.5.0-beta01.module",
"group": "androidx.sqlite",
"module": "sqlite-jvm",
"version": "2.5.0-beta01"
}
}
So every attribute in the jvmRuntimeElements matches the requested ones.
hm...@google.com <hm...@google.com> #9
Oh,i missed the libraryelements one from the list. Looks like jvmRuntimeElements does not publish that attribute and the android one does (and it's a wrong one as mentioned before). So it looks like that could the reason for the wrong variant resolution.
da...@google.com <da...@google.com> #10
The library is from androidx, we are using
I did also notice the compile classpath is fine, after all it compiles correctly and the APIs do resolve in the IDE, but at runtime it fails.
da...@google.com <da...@google.com> #11
So far we have found that from alpha12 (good version) to alpha13 (bad version) of androidx.sqlite, one change that affected the metadata was the upgrade from Gradle 8.11.1 to 8.12, this is a diff of the metadata:
Notice the removal of the org.gradle.libraryelements
attribute. The attribute is also missing with Gradle 8.13-rc1
ow...@google.com <ow...@google.com>
hm...@google.com <hm...@google.com> #12
Update on libraryelements attribute missing in jvm target publications with Gradle 8.12 - Jetbrain are saying it will be fixed after
By the way I have noticed a weird behaviour - if you do ./gradlew publish in your project libraryelements is not there for jvm publications but if you do ./gradlew publishJvmPublicationToMavenRepository it's there
Daniel, Owen, let me know if this is enough info to proceed further with a fix.
hm...@google.com <hm...@google.com> #13
For the issue of the android publications where "org.gradle.libraryelements" = "jar" instead of "aar" - that was fixed in AGP 8.10 canary 7. Please feel free to try it out and report back. Thank you
da...@google.com <da...@google.com>
au...@google.com <au...@google.com> #14
FYI danysantiago@ we have upgraded to 8.10.0-alpha07 in androidx.
Description
Applying the newer AGP KMP plugin to androidx.sqlite breaks the Gradle metadata such that a JVM project depending on the artifact will attempt (and fail) to use the android artifact instead of the JVM one.
This was originally reported in SQLite KMP b/396148592
Here is a diff on the metadata, left is before AGP KMP is used (i.e. after reverting the changes in this CL ) and right is with AGP KMP applied: https://diff.googleplex.com/#key=EY2FqaJWQbUQ
Let me know if you need a sample project, but if you create a new JVM or Kotlin project and depend on
androidx.sqlite:sqlite:2.5.0-beta01
and try to use classes from it, it will fail at runtime with a class not found exception. When inspecting the deps via:dependencies
you will notice it attempts to use the-android
artifact instead of the-jvm
one: