Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
After update to Fragments 1.2.0-alpha01, it seems the same exception still happens (Also tried update appcompat:1.1.0-rc01)
The latest example project was attached
The latest example project was attached
gm...@gmail.com
Sorry, <ma...@cyberagent.co.jp> is also my mail.
jb...@google.com
Thanks for confirming, I was able to reproduce your issue.
gm...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit e6ce39f90140f19068852a99713e19680ff20559
Author: Ian Lake <ilake@google.com>
Date: Wed Jul 24 14:30:55 2019
Remove cancelled postponed transactions when popped
When popping a postponed fragment transaction,
remove the transaction from the list of postponed
transactions when cancelling it.
This prevents cases where we attempt to execute
the postponed transaction despite it already
being cancelled.
Test: new test passes
BUG: 138251858
Change-Id: Ie2f23923ad761a35c43df8716e46e51183dbc010
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PrimaryNavFragmentTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
https://android-review.googlesource.com/1090762
https://goto.google.com/android-sha1/e6ce39f90140f19068852a99713e19680ff20559
Branch: androidx-master-dev
commit e6ce39f90140f19068852a99713e19680ff20559
Author: Ian Lake <ilake@google.com>
Date: Wed Jul 24 14:30:55 2019
Remove cancelled postponed transactions when popped
When popping a postponed fragment transaction,
remove the transaction from the list of postponed
transactions when cancelling it.
This prevents cases where we attempt to execute
the postponed transaction despite it already
being cancelled.
Test: new test passes
BUG: 138251858
Change-Id: Ie2f23923ad761a35c43df8716e46e51183dbc010
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PrimaryNavFragmentTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
de...@gmail.com
eu...@gmail.com
Turns out that this was actually a more serious, long standing issue with Fragments that was just exposed by more recent changes.
We'll be releasing a new 1.1.0-rc04 for Fragments with this fix and update Navigation 2.1 to depend on it.
We'll be releasing a new 1.1.0-rc04 for Fragments with this fix and update Navigation 2.1 to depend on it.
ve...@gmail.com
Same issue.
tf...@gmail.com
OP here, just to add that even though I originally said:
(...) and now I have to set a
transitionNameinstead to get the same effect I used to get withtransitionGroup=true.
I don't think that's actually the case, especially on screens with a RecyclerView. There's still a difference there between setting a transitionName now and having transitionGroup=true in previous versions, just like it was said
sm...@gmail.com
There is a regression introduced in 1.3.4 with transitionGroup=true. I posted the exact code that should be fixed in this ticket: https://issuetracker.google.com/issues/188569366
ti...@gmail.com
On: kotlin 1.5.0 gradle plugin 7.1.0-alpha02 fragment 1.3.0 appcompat 1.3.0-beta01 activity 1.3.0-alpha03 navigation 2.4.0-alpha02
The issue suddenly started to occur again (I tried updating fragment before), but I just updated the gradle plugin and navigation.
de...@gmail.com
Thats because appcompat > rc01 depends in Fragment 1.3.4
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 06769a572f7003fb662109b595952d6ff5c63a74
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Jun 08 16:35:28 2021
Fix fragment transitions in new state manager
In aosp/1679887 we attempted to fix doing shared element transitions on
ViewGroups with the transitionGroup="false" attribute set. That change
caused a regression in enter and exit transitions, and could also cause
errors if the entering fragment attempted to transition more views than
the exiting fragment.
This change makes it so that fragments no longer looks at all of the
views in the hierarchy of sharedelement views. We depend on transition
names to determine if a view is a shared element, and if a shared
element is a viewgroup with transitionGroup="true", the entering/exiting
transition should ignore that viewgroup and transition its unnamed
children.
RelNote: "Fixed regression in shared element transtions caused by
aosp/1679887. Setting transitionGroup=\"true\" will now work correctly and
shared elements will no longer throw `IndexOutOfBoundsException`s."
Test: FragmentSharedElementTransitionTest
Bug: 188679569
Bug: 188969304
Change-Id: I164845639cae1f64cf54e4e89b2a24d7eb649beb
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentSharedElementTransitionTest.kt
A fragment/fragment/src/androidTest/res/layout/scene6.xml
A fragment/fragment/src/androidTest/res/layout/scene7.xml
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
https://android-review.googlesource.com/1732732
Branch: androidx-main
commit 06769a572f7003fb662109b595952d6ff5c63a74
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Jun 08 16:35:28 2021
Fix fragment transitions in new state manager
In aosp/1679887 we attempted to fix doing shared element transitions on
ViewGroups with the transitionGroup="false" attribute set. That change
caused a regression in enter and exit transitions, and could also cause
errors if the entering fragment attempted to transition more views than
the exiting fragment.
This change makes it so that fragments no longer looks at all of the
views in the hierarchy of sharedelement views. We depend on transition
names to determine if a view is a shared element, and if a shared
element is a viewgroup with transitionGroup="true", the entering/exiting
transition should ignore that viewgroup and transition its unnamed
children.
RelNote: "Fixed regression in shared element transtions caused by
aosp/1679887. Setting transitionGroup=\"true\" will now work correctly and
shared elements will no longer throw `IndexOutOfBoundsException`s."
Test: FragmentSharedElementTransitionTest
Bug: 188679569
Bug: 188969304
Change-Id: I164845639cae1f64cf54e4e89b2a24d7eb649beb
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentSharedElementTransitionTest.kt
A fragment/fragment/src/androidTest/res/layout/scene6.xml
A fragment/fragment/src/androidTest/res/layout/scene7.xml
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
jb...@google.com
This has been fixed internally and will be part of the Fragment 1.4.0-alpha03 release. You can verify that it works with your app by following the instructions at SNAPSHOTs and using a buildId of 7444280+.
os...@gmail.com
I had the crash starting from 1.3.4 on animation SharedAxis:
java.lang.UnsupportedOperationException: removeView(View) is not supported in AdapterView
at android.widget.AdapterView.removeView(AdapterView.java:543)
at android.view.ViewOverlay$OverlayViewGroup.add(ViewOverlay.java:198)
at android.view.ViewGroupOverlay.add(ViewGroupOverlay.java:72)
at androidx.transition.TransitionUtils.createViewBitmap(TransitionUtils.java:108)
at androidx.transition.TransitionUtils.copyViewImage(TransitionUtils.java:64)
at androidx.transition.Visibility.onDisappear(Visibility.java:404)
at androidx.transition.Visibility.createAnimator(Visibility.java:257)
at androidx.transition.Transition.createAnimators(Transition.java:744)
at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:480)
at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:480)
at androidx.transition.Transition.playTransition(Transition.java:1808)
at androidx.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:300)
at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1088)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2769)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1745)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7772)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:967)
at android.view.Choreographer.doCallbacks(Choreographer.java:791)
at android.view.Choreographer.doFrame(Choreographer.java:726)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:952)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7356)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:940)
But it disappeared on 1.4.0-SNAPSHOT starting from 7444280. Is this crash relates to this issue? And will it be included to 1.3.5?
Thanks!
gm...@gmail.com
Seems to be fixed in 1.3.5, thanks!
Description
Component used: Fragment
Version used: 1.3.4
Devices/Android versions reproduced on: Pixel 3 running Android 11
Sample project:https://github.com/tfcporciuncula/playground/tree/transition-issue (branch
transition-issue)I've learned from
transitionGroup=truecan be important in some cases, even when no shared element is involved in the transition, and from my experience it usually makes my Material motion fragment transitions (e.g.MaterialSharedAxis) look better.Starting from fragment 1.3.4, most likely because of
transitionGroup=trueor not doesn't make a difference anymore, and now I have to set atransitionNameinstead to get the same effect I used to get withtransitionGroup=true.I'm attaching two videos, both recorded with fragment 1.3.4 and transition 1.4.1, and you can compare the difference between running a material shared axis transition with and without a
transitionNamedefined. There are no shared elements involved in the transition, but defining or not atransitionNamein the root of the fragment layouts have a big impact in the transitions, and that seems to be wrong.