Status Update
Comments
am...@google.com <am...@google.com>
am...@google.com <am...@google.com> #2
Is this not a bug in AGP? It doesnt feel like an androidx issue.
ca...@gmail.com <ca...@gmail.com> #3
Probably yes, feel free to reroute or CC the right people. I was not 100% sure since the project uses the androidXMultiplatform
DSL, but looking at the DSL it simply forwards things to AGP.
ki...@gmail.com <ki...@gmail.com> #4
Do you have an example of what a broken consuming project looks like? which plugins are they applying?
am...@google.com <am...@google.com> #5
I've uploaded a sample project, to repro run: ./gradlew test
It is a simple Kotlin JVM project, it only uses plugins { kotlin("jvm") version "2.1.10" }
I was also able confirm that without AGP KMP (
[Deleted User] <[Deleted User]> #6
Looking at the Gradle metadata diff ("org.gradle.libraryelements": "jar"
? Should that be an aar
instead?
`
lo...@gmail.com <lo...@gmail.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...
t....@gmail.com <t....@gmail.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.
[Deleted User] <[Deleted User]> #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.
ad...@gmail.com <ad...@gmail.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.
[Deleted User] <[Deleted User]> #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
ch...@google.com <ch...@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.
[Deleted User] <[Deleted User]> #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
ja...@gmail.com <ja...@gmail.com> #14
FYI danysantiago@ we have upgraded to 8.10.0-alpha07 in androidx.
ch...@google.com <ch...@google.com> #15
The original bug is caused by the change in 26.0.0 where flings can continue, even if the view is not actually moving. This was done to allow AppBarLayout to react to "resting" flings through nested scrolling.
The issue here is that once AppBarLayout has finished reacting to the resting fling (reach its end) the fling can still continue. Therefore even though nothing is moving on screen, when the user touches the screen they are just cancelling the invisible fling. Subsequent touches then do as expected (clicks, etc).
The fix here is more of a workaround than a proper fix. Here AppBarLayout detects when it has finished its fling handling, and then stops the nested scroll on the scrolling view (RV, etc).
[Deleted User] <[Deleted User]> #16
If you want to stuff this in a base class and know you're not setting any other behaviors on your appbarlayouts, you can put it in a base class in an overridden setLayoutParameters method
ch...@google.com <ch...@google.com> #17
@CoordinatorLayout.DefaultBehavior(FixAppBarLayoutBehavior.class)
public CustomAppBarLayout extends AppBarLayout {
// ....
}
That way, you do not have to mess around with your layouts or the LayoutParams.
am...@google.com <am...@google.com> #18
ar...@google.com <ar...@google.com> #19
az...@gmail.com <az...@gmail.com> #20
dg...@gmail.com <dg...@gmail.com> #21
[Deleted User] <[Deleted User]> #22
jo...@gmail.com <jo...@gmail.com> #23
dr...@gmail.com <dr...@gmail.com> #24
fa...@gmail.com <fa...@gmail.com> #25
ps...@gmail.com <ps...@gmail.com> #26
dr...@gmail.com <dr...@gmail.com> #27
dr...@gmail.com <dr...@gmail.com> #28
al...@google.com <al...@google.com> #29
am...@google.com <am...@google.com> #30
ps...@gmail.com <ps...@gmail.com> #31
de...@gmail.com <de...@gmail.com> #32
de...@gmail.com <de...@gmail.com> #33
pr...@gmail.com <pr...@gmail.com> #34
[Deleted User] <[Deleted User]> #35
ay...@gmail.com <ay...@gmail.com> #36
9g...@gmail.com <9g...@gmail.com> #37
[Deleted User] <[Deleted User]> #38
za...@gmail.com <za...@gmail.com> #39
sh...@gmail.com <sh...@gmail.com> #40
ja...@gmail.com <ja...@gmail.com> #41
de...@gmail.com <de...@gmail.com> #42
pe...@gmail.com <pe...@gmail.com> #43
Hoping to see a proper solution, currently this is my workaround until then. Not the best workaround, but does work for me:
Override
public void onScrollStateChanged(final int state)
{
super.onScrollStateChanged(state);
if (state == RecyclerView.SCROLL_STATE_SETTLING)
{
this.stopScroll();
}
}
pe...@gmail.com <pe...@gmail.com> #44
hu...@gmail.com <hu...@gmail.com> #45
[Deleted User] <[Deleted User]> #46
an...@gmail.com <an...@gmail.com> #47
[Deleted User] <[Deleted User]> #49
ha...@gmail.com <ha...@gmail.com> #50
ri...@gmail.com <ri...@gmail.com> #51
fa...@gmail.com <fa...@gmail.com> #52
de...@gmail.com <de...@gmail.com> #53
au...@google.com <au...@google.com> #54
sh...@google.com <sh...@google.com> #55
The issue is that after a fling event, the nested scrolling api has no way of informing the RecyclerView that a fling animation has reached the end of the scroll distance, and thus sometimes, the scroll animation is continuing in the background such that when the first tap occurs, it is interpreted as an interruption to the fling, which puts the RV back into its scrolling state as if the user started scrolling, and thus, the touch events don't propagate down to the child to cause a click to occur.
Some larger changes are needed to fix this (and at least one other) issue, and I'm in the midst of that work.
Sorry for the inconvenience.
za...@gmail.com <za...@gmail.com> #56
dr...@gmail.com <dr...@gmail.com> #57
May I ask in this version, fix this issue?
sh...@google.com <sh...@google.com> #58
sp...@gmail.com <sp...@gmail.com> #59
sh...@google.com <sh...@google.com> #60
When RecyclerView is flung, and it hits the bounds of it's scrollable distance and has a NestedScrollingParent, it continues to animate the fling so that the NestedScrollingParent might receive the events and scroll. RV has no way of knowing if any NestedScrollingParents have hit their bounds, and thus it continues the fling even if nothing is moving.
On top of that, when RV is flinging and is touched, it stops it's fling and prevents the touch event from causing a click, so that a touch meant to stop a fling doesn't cause a click.
Put those two things together and you get the perceived behavior that when an RV is flung, and stops, the next touch event doesn't click.
I'm pursuing a but can't make any promises as to when it will be available. Sorry for the inconvenience.
ha...@gmail.com <ha...@gmail.com> #61
pr...@gmail.com <pr...@gmail.com> #63
su...@gmail.com <su...@gmail.com> #64
sh...@google.com <sh...@google.com> #65
ny...@gmail.com <ny...@gmail.com> #66
fa...@gmail.com <fa...@gmail.com> #67
le...@gmail.com <le...@gmail.com> #68
pi...@gmail.com <pi...@gmail.com> #69
yi...@gmail.com <yi...@gmail.com> #70
de...@gmail.com <de...@gmail.com> #71
t....@gmail.com <t....@gmail.com> #72
cn...@gmail.com <cn...@gmail.com> #73
za...@gmail.com <za...@gmail.com> #74
da...@gmail.com <da...@gmail.com> #75
[Deleted User] <[Deleted User]> #76
ro...@gmail.com <ro...@gmail.com> #77
an...@googlemail.com <an...@googlemail.com> #78
sh...@google.com <sh...@google.com> #79
I am actively solving this issue. In fact, the CL that makes the necessary changes in RecyclerView has been submitted to aosp (as AndroidX is now developed there):
The fix is coming by way of an update to nested scrolling and thus need to be implemented across multiple classes. For example, for the issue to be fixed when a RecyclerView is in a CoordinatorLayout with the AppBarLayout.Behavior, implementation has to be done in each of those classes.
Unfortunately the rollout of these changes is also going to take some time, but do know that we are taking as seriously as we can.
fr...@gmail.com <fr...@gmail.com> #80
sh...@google.com <sh...@google.com> #81
sh...@gmail.com <sh...@gmail.com> #83
I've tried both java and xml ways but in vain.
Checked on emulator running on 5.0 and physical device running on 7.1.1
Any ideas ?
sh...@gmail.com <sh...@gmail.com> #84
ss...@gmail.com <ss...@gmail.com> #85
am...@gmail.com <am...@gmail.com> #87
am...@google.com <am...@google.com>
pa...@gmail.com <pa...@gmail.com> #88
Dear Google developers, can you please take it on priority?
we...@gmail.com <we...@gmail.com> #89
kp...@gmail.com <kp...@gmail.com> #90
I think it is related with NestedScrollingChild3 and NestedScrollingParent3 and since 1.1.0-alpha01 RecyclerView and CoordinatorLayout implements those.
sh...@google.com <sh...@google.com> #91
sh...@google.com <sh...@google.com> #92
androidx.core 1.1.0-alpha01
androidx.appcompat 1.1.0-alpha01
androidx.coordinatorlayout 1.1.0-alpha01
androidx.recyclerview 1.1.0-alpha01
androidx.swiperefreshlayout 1.1.0-alpha01
(and an upcoming release of the android material design library)
This issue should be fixed!
I'm closing it, but do let me know if it seems to still be happening!
pa...@outlook.com <pa...@outlook.com> #93
This is a BottomSheet with a NestedScrollView, it does not contain any RecyclerView:
<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout
xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="match_parent"
android:clipChildren="false">
<com.google.android.material.appbar.AppBarLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<!--Other views and tested with and without a Toolbar inside-->
</com.google.android.material.appbar.AppBarLayout>
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/white"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:paddingBottom="8dp"
android:paddingTop="8dp">
<!--Enough views to create a scrollable area-->
</LinearLayout>
</androidx.core.widget.NestedScrollView>
</androidx.coordinatorlayout.widget.CoordinatorLayout>
In this scenario (with or without a Toolbar view in the AppBarLayout parent) whenever you scroll the NestedScrollView to the top or to the bottom and try to tap on any items inside the LinearLayout the first tap will always fail to initiate the expected action, forcing you to do a second tap since after the first one the taps start working. This happens whenever you scroll to the top or bottom of the NestedScrollView every single time, even after you tap for a second or n times.
I am using the library versions or most up to date (a couple were already updated since then) the Assignee listed in his last reply.
sh...@google.com <sh...@google.com> #94
There isn't a public bug that I'm aware of that is tracking that precise work, but know that your specific issue will be fixed in an upcoming release of the Android Material Design library.
pa...@outlook.com <pa...@outlook.com> #95
me...@google.com <me...@google.com> #96
yq...@gmail.com <yq...@gmail.com> #97
pv...@gmail.com <pv...@gmail.com> #98
recyclerview-v7:28.0.0
vz...@gmail.com <vz...@gmail.com> #99
sh...@google.com <sh...@google.com> #100
The AndroidX version of RecyclerView picks up where that version left off and is currently supported:
sh...@google.com <sh...@google.com> #101
sa...@gmail.com <sa...@gmail.com> #102
[Deleted User] <[Deleted User]> #103
[Deleted User] <[Deleted User]> #104
sh...@google.com <sh...@google.com> #105
te...@gmail.com <te...@gmail.com> #106
sh...@google.com <sh...@google.com> #107
ma...@gmail.com <ma...@gmail.com> #108
ma...@gmail.com <ma...@gmail.com> #109
but it's working fine if I double tap it quickly
sh...@google.com <sh...@google.com> #110
bo...@gmail.com <bo...@gmail.com> #111
Updated my AndroidX dependencies and fixed the issue with appbarlayout/bottomnav/recyclerview. Did not try out MotionLayout
Description
Version used: 26.0.2
Theme used: Theme.AppCompat.NoActionBar
Devices/Android versions reproduced on: AVD API 25
I just upgraded to API 26 and support library 26.0.2. But I found that my RecyclerView items is not clickable right after the scrolling. If you wait for a second, it will work. But if you click the item immediately, it won't. Even if the RecyclerView is not scrolling at all(e.g. has scrolled to the top).
When I downgraded to support library 25.4.0 everything goes fine again. The key point is that my RecyclerView is in a CoordinatorLayout and has a SCROLL_FLAG_SCROLL flag on my Toolbar of the AppBarLayout. If I don't use this flag, then this problem will disappear.
I've tried to add focusable="false" to the CoordinatorLayout but still had no luck.
Is there any way to disable this behavior? Because it's really annoying to click twice to trigger the click event.
I think the problem is the scrollState of the RecyclerView. When it's stopped scrolling, it's not changed to SCROLL_STATE_IDLE immediately. Looking into the source code of RecyclerView, I found there's a ViewFlinger controlling the scroll state. When I fling down to scroll to the top, it's not calling setScrollState(SCROLL_STATE_IDLE) immediately. Instead, it wait for a while to trigger this method. The more fast I fling, the more time I need to wait. It just like the RecyclerView is still scrolling in the background. Because the scroller.isFinished() doesn't return true right after the RecyclerView stop scrolling when it touched the top. Maybe it's a bug of the RecyclerView when it's in a CoordinatorLayout.
The attachment is a screen recording of this behavior.
<android.support.design.widget.CoordinatorLayout
android:id="@+id/coordinateLayout"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.design.widget.AppBarLayout
android:id="@+id/fragmentAppBar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:elevation="0dp"
android:background="@null">
<include
android:id="@+id/dynamicActionBarHolder"
layout="@layout/dynamic_action_bar"/>
</android.support.design.widget.AppBarLayout>
<android.support.v4.widget.SwipeRefreshLayout
android:id="@+id/pullToRefreshMailRecycler"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<android.support.v7.widget.RecyclerView
android:id="@+id/mailRecyclerView"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
</android.support.v4.widget.SwipeRefreshLayout>
</android.support.design.widget.CoordinatorLayout>
layout/dynamic_action_bar.xml
<FrameLayout xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="?attr/actionBarSize"
app:layout_scrollFlags="scroll"
android:clickable="true"
android:background="?theme.dynamicActionBarBackground">
<ImageButton
android:id="@+id/dynamicAcbMenuIcon"
android:layout_width="?attr/actionBarSize"
android:layout_height="?attr/actionBarSize"
android:background="@drawable/article_explicit_button_background"
android:src="?theme.menuIcon"/>
<RelativeLayout
android:id="@+id/dynamicAcbTitleHolder"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginStart="?attr/actionBarSize"
android:paddingTop="5dp"
android:paddingBottom="5dp"
android:paddingEnd="5dp"
android:layout_gravity="center_vertical">
<TextView
android:id="@+id/dynamicAcbTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textSize="@dimen/action_bar_title_portrait_size"
android:textColor="?theme.listItemTitleColor"
android:ellipsize="end"
android:text="ActionBar"/>
<TextView
android:id="@+id/dynamicAcbSubtitle"
android:layout_below="@+id/dynamicAcbTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textSize="@dimen/action_bar_subtitle_portrait_size"
android:textColor="?theme.listItemTitleColor"
android:ellipsize="end"
android:text="If you say so"/>
</RelativeLayout>
</FrameLayout>