When a snack bar is hidden and its show() method is called, it will be added to the target parent, and at this moment the parent view will set the layout params to the snack bar, with the same existing margins if any. Therefore if the margins are already updated with extra margins, the original margins will be incorrectly updated. This CL introduces a flag to tells this situation from other "real" scenarios in which clients want to update their custom margins.
Resolves https://github.com/material-components/material-components-android/issues/2666
PiperOrigin-RevId: 445159923
On API 21 & 22, the borderless ripple will go behind the container view under certain conditions. Setting a mask when creating the ripple drawable to restrain the ripple inside view bounds somehow solves the issue.
Resolves https://github.com/material-components/material-components-android/issues/929
PiperOrigin-RevId: 444595599
On Lollipop, when first assigned as View's background, RippleDrawable won't/can't propagate states to its content drawable. This causes the issue that the state relevant features like stroke colors are not correctly updated when the background is recreated. Explicitly assigns states to the content drawable to fix the issue.
Resolves https://github.com/material-components/material-components-android/issues/1422
PiperOrigin-RevId: 442676637
In SwipeDismissBehavior, when dismissing views according to the horizontal velocity instead of position delta, we would still using position delta to decide the dismissing direction, which, unfortunately, makes the view always be dismissed from left to right because of the "less than" logic we are using doesn't really take the equaling case into account. Fixes this by using the velocity direction to dismiss the view instead.
Resolves https://github.com/material-components/material-components-android/issues/1868
PiperOrigin-RevId: 442553318
When calculating text width to decide the icon position with textStart/End alignment, we missed accounting for multiline text. Fixes this by calculating each line's width separately and take the widest one to decide the icon position.
Resolves https://github.com/material-components/material-components-android/issues/2007
PiperOrigin-RevId: 440982189
When an AppBarLayout is loaded, it will load the attribute and set up a non-forcing pending action. However when it's measured, the current scroll state will be saved and restored, which will override the non-forcing pending action. This behavior is incorrect - if there's a pending action, we shouldn't restore the scrolling state because it's meant to be changed.
Resolves https://github.com/material-components/material-components-android/issues/2629
PiperOrigin-RevId: 440960254
When the icon gravity is textTop, we are using the smaller one of the calculated height from text paint and the text layout height to decide the icon position. This is wrong when there are multiple lines of text since the text paint is always single line and always shorter than the actual height.
Fixes this by returning the actual layout height whenever there are multiple lines of text to fix the issue.
Resolves https://github.com/material-components/material-components-android/issues/2619
PiperOrigin-RevId: 440923733
When the date picker goes back from background to foreground, the onStart() method will be called and make enableEdgeToEdge() be called again. This will make it incorrectly use the header height and top padding already adjusted with system inset as the original height and padding, and thus add the inset multiple times.
Creates a flag to only enable edge-to-edge once to fix the issue.
Resolves https://github.com/material-components/material-components-android/issues/2628
PiperOrigin-RevId: 440110562
Before, its value was being overwritten in code where we set the default popup background, so we should null it in the Material styles.
PiperOrigin-RevId: 437813304
