Status Update
No update yet.
Comments
il...@google.com
ti...@gmail.com
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request from
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
il...@google.com
Re #2 - did you already file a separate bug with a sample project that reproduced your transition issue? I don't see any issues filed from you or we would have looked at it for the Fragment 1.3.2, 1.3.3, 1.3.4, or 1.4.0-alpha01 releases (as you can see there were fixes for reported issues in every one of those releases).
The issue reported here and shown in the sample project is unique to Fragment 1.3.4 or higher, so would be unrelated to any issue that existed in Fragment 1.3.1.
gm...@gmail.com
In our case (screen with buttons -> horizontal MaterialSharedAxis transition -> screen with TextView & RecyclerView) transition looks... not good since Fragment 1.3.4, and specifying transitionName fixes it only partially. We can share a sample project if needed.
jb...@google.com
Yes, please share your sample project.
gm...@gmail.com
Here it is.
With Fragment 1.3.3, screen slides as a whole, as intended, if it has a background or android:transitionGroup="true". I personally would prefer true to be the default, but this is consistent with the documentation, so no complaints.
Without these flags RecyclerView content just fades in (no sliding, maybe it's a bug too?); reverse animation is OK.
With Fragment 1.3.4, RecyclerView content appears and window background changes abruptly, without any animation. On going back background changes immediately again. transitionGroup seems to have no effect.
With transitionName specified on both layouts, the effect is somewhat better (background and RecyclerView fade in and slide), but still not perfect:
- Title slides with different speed than RecyclerView
- On going back RecyclerView text temporarily grows darker
de...@gmail.com
Check out my sample project on GitHub:
eu...@gmail.com
I also have this issue, but I don't think setting transitionName works around the issue completely. transitionGroup=true should make the transition to run on ViewGroup as a whole, but setting transitionName makes it run on the ViewGroup and its children.
ve...@gmail.com
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
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
ap...@google.com
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.