Status Update
Comments
jb...@google.com <jb...@google.com> #2
I'm marking this as "won't fix" as there's nothing Compose here can do, as this is a platform quirk that has been adjusted to be more predictable in recent API versions.
The crux of the issue here is the fitSystemWindows
in the extra View
, like you mentioned, and a platform change in API 30.
Prior to API 30, window insets were dispatched through the view hierarchy in a non-intuitive way: Rather than being a full breadth-first traversal, they would be dispatched in preorder. If the insets were consumed at any point (like if you use fitSystemWindows
), then the preorder would prevent insets from being dispatched to the rest of the view hierarchy. This is very unintuitive: It meant that sibling views (or views deeper in the tree) could stop later views from receiving the dispatch of insets.
In API 30, this behavior was changed to be more intuitive: Now, insets are dispatched in a top-down manner, so they can't be consumed in this weird, cross-tree way.
There's a couple solutions here:
- Avoid
fitSystemWindows
from views if you're handling insets manually - Override
dispatchApplyWindowInsets
in the view groups above where you havefitSystemWindows
defined, and manually perform the new, non-broken dispatching behavior. You can see a comparison of the two methods here:https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/view/ViewGroup.java;l=7341-7371;drc=6411c81462e3594c38a1be5d7c27d67294139ab8
Description
Version used:
Fragment: 1.5.5
Navigation: 2.5.0
Devices/Android versions reproduced on: Multiple devices in production
We have no way of knowing from where this crash is happening as the stacktrace contains only files from Android framework.
Stacktrace:
Exception java.lang.IllegalArgumentException:
at androidx.fragment.app.FragmentStateManager.void createView() (FragmentStateManager.java:514)
at androidx.fragment.app.FragmentStateManager.void moveToExpectedState() (FragmentStateManager.java:261)
at androidx.fragment.app.FragmentStore.void moveToExpectedState() (FragmentStore.java:113)
at androidx.fragment.app.FragmentManager.void moveToState(int,boolean) (FragmentManager.java:1433)
at androidx.fragment.app.FragmentManager.void dispatchStateChange(int) (FragmentManager.java:2977)
at androidx.fragment.app.FragmentManager.void dispatchViewCreated() (FragmentManager.java:2888)
at androidx.fragment.app.Fragment.void performViewCreated() (Fragment.java:3129)
at androidx.fragment.app.FragmentStateManager.void createView() (FragmentStateManager.java:552)
at androidx.fragment.app.FragmentStateManager.void moveToExpectedState() (FragmentStateManager.java:261)
at androidx.fragment.app.FragmentManager.void executeOpsTogether(java.util.ArrayList,java.util.ArrayList,int,int) (FragmentManager.java:1890)
at androidx.fragment.app.FragmentManager.void removeRedundantOperationsAndExecute(java.util.ArrayList,java.util.ArrayList) (FragmentManager.java:1823)
at androidx.fragment.app.FragmentManager.boolean execPendingActions(boolean) (FragmentManager.java:1760)
at androidx.fragment.app.FragmentManager$5.void run() (FragmentManager.java:547)
at android.os.Handler.handleCallback (Handler.java:942)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:235)
at android.os.Looper.loop (Looper.java:350)
at android.app.ActivityThread.main (ActivityThread.java:8798)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:703)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:911)
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).