In certain situations drawable states won't be correctly propagated to the background drawable wrapped in a LayerDrawable during setting view background. Always explicitly updates the drawable state to fix the issue.
Resolves https://github.com/material-components/material-components-android/issues/2670
PiperOrigin-RevId: 446786432
When the collapsing title is fully expanded, the current logic won't update the linear text setting correctly to false, which may result in the issue that the type face is not updated correctly. Fixes this by always updating linear text settings when the available text width is not 0.
Also refactors the typeface relevant logic so we will decide if we should recreate the static text layout in a consistent way.
Resolves https://github.com/material-components/material-components-android/issues/2463
PiperOrigin-RevId: 446735260
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.
PiperOrigin-RevId: 445920587
This CL also cleans up and fixes the edit text background setting logic - when the edit text is an autocomplete text view and provides its own background, we won't override the background by trying to add ripples to it.
Later they should be split again from the main class with other box-background-relevant logic.
Resolves https://github.com/material-components/material-components-android/issues/1431
PiperOrigin-RevId: 445486075
Somehow Context.obtainStyledAttributes() with a provided style resource crashes if some attributes in the style are resolved to be macros. Using ContextThemeWrapper to wrap the context with the style doesn't have this issue. Workarounds this by always wrapping the context to retrieve attributes.
PiperOrigin-RevId: 445451176
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
