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
Fixed by checking for the input type instead of the key listener (which remains as non null when updating the input type).
PiperOrigin-RevId: 436308197
Before, in requestRectangleOnScreen we were setting the text input layout’s rectangle to a specific and constant position, which caused the zoomed in screen to be fixed to the left instead of following the input text as it was typed. We should use the edit text’s rectangle’s position first, then adjust for the text field’s height (which includes the helper/error text), then use that updated rectangle on the super call of the method.
PiperOrigin-RevId: 435402032
