Status Update
No update yet.
Comments
il...@google.com
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
fitSystemWindowsfrom views if you're handling insets manually - Override
dispatchApplyWindowInsetsin the view groups above where you havefitSystemWindowsdefined, 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
[Deleted User] <[Deleted User]>
Using composable version 1.2.1, I could fix it using:
override fun onCreate(bundle: Bundle?) {
WindowCompat.setDecorFitsSystemWindows(window, false)
super.onCreate(bundle)
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.Q){
window.setFlags(WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS, WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS)
}
}
Then statusBarsPadding works as expected on Api 29
il...@google.com
[Deleted User] <[Deleted User]>
jb...@google.com
Looks like this never worked in previous Fragment testing versions. Not sure what's different between setting the theme on a FragmentScenario vs directly on an Activity.
[Deleted User] <[Deleted User]>
ru...@gmail.com
thanks this is working for me launchFragmentInContainer<CountryFragment>(themeResId = R.style.AppTheme)
im using this dependencies
androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1' androidTestImplementation "androidx.test.espresso:espresso-contrib:3.5.1" androidTestImplementation "androidx.test:rules:1.5.0" debugImplementation 'androidx.fragment:fragment-testing:1.5.3'
Description
Maybe this issue is related to this one:
I’m testing a fragment using androidx.fragment:fragment-testing:1.3.0-rc01 and I have a problem. I initialize it doing this:
My style is:
onCreateOptionsMenu(menu: Menu, inflater: MenuInflater) in the fragment is not called and the actionbar is hide. If I use R.style.ThemeOverlay_MaterialComponents_Dark_ActionBar for instance , onCreateOptionsMenu is called and the actionbar is shown but I get this error:
And using R.style.Theme_MaterialComponents I have the same problem as in the first case. It could be a problem with fragment scenario? I could create a toolbar but I think that should work using my custom AppTheme. Maybe is related to the injection of the Activity with some default theme.
Thanks.