[MaterialContainerTransform] IllegalStateException: "End view bounds must not be null, make sure the end view is laid out and measured"
See original GitHub issueI am not sure if this should be a question or a bug report, but after updating to material 1.2.0-beta01 I am starting to see random crashes in production when using MaterialContainerTransform as a sharedelementreturntransition. Same issue is there in the 1.3.0 alpha1.
I cannot reproduce this on any of my devices, but in production there is a 5% crash rate.
StackTrace:
Fatal Exception: java.lang.IllegalStateException: End view bounds must not be null, make sure the end view is laid out and measured
at com.google.android.material.transition.MaterialContainerTransform.createAnimator(MaterialContainerTransform.java:889)
at androidx.transition.Transition.createAnimators(Transition.java:747)
at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:480)
at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:480)
at androidx.transition.Transition.playTransition(Transition.java:1821)
at androidx.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:301)
at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1102)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3310)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2200)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9065)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:999)
at android.view.Choreographer.doCallbacks(Choreographer.java:797)
at android.view.Choreographer.doFrame(Choreographer.java:732)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:984)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:237)
at android.app.ActivityThread.main(ActivityThread.java:8016)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1076)
How can I make sure that the end view is laid out and measured?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:17 (5 by maintainers)
Top Results From Across the Web
MaterialContainerTransform transition is not Working on Return
I dynamically set the ImageView transitionName in each RecyclerView item, and pass that to the destination Fragment which then copies the ...
Read more >MaterialContainerTransform - Android Developers
This transition captures a start and end View which are used to create a Drawable which will be added to the view hierarchy....
Read more >Shared Element using MaterialContainerTransform in Android
This transition captures a start and end View which are used to create a Drawable which will be added to the view hierarchy....
Read more >CSS View Transitions Module Level 1 - W3C
View Transitions is a set of API that allow DOM changes to smoothly animate ... The element will not participate in a view...
Read more >Postponed Shared Element Transitions (part 3b)
Whether or not the shared elements' end values will be calculated before ... measured and laid out within the * activity's view hierarchy....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for looking into this!
Ok I’ve looked into this a bit more considering the androidx/framework
ChangeBounds
transition, which is comparable toMaterialContainerTransform
. Whether intentionally or not, it seems likeChangeBounds
will short-circuit before accessing null bounds objects, because of this view parent check and the fact that the parent property is only set when non-null bounds are set.So I think it makes sense to be consistent with that behavior, even if it means some developers won’t find out about this potential misconfiguration. Assuming we don’t find any other reasoning, I will change our IllegalStateException to be an early return with a log warning.