In toolbar styles we use android:theme to override text and icon colors and set ?attr/colorControlNormal to ?attr/colorOnPrimary, which is the same color (white) in the light mode as the menu background. To override this behavior again, we need to use ?attr/popupTheme and set ?attr/colorControlNormal to ?attr/colorOnSurface.
Resolves https://github.com/material-components/material-components-android/issues/553
PiperOrigin-RevId: 392003704
On SDK < 23 if the icon is not a TintAwareDrawable, DrawableCompat.wrap() will return a new drawable which wraps the original drawable. However in the original logic after we set the tint to the icon, we didn't really set the tinted icon back to the tab or the image view, therefore the tint is not showing.
Moves the tint logic to updateTextAndIcon() to ensure tinted icons will be used in the image view.
Resolves https://github.com/material-components/material-components-android/issues/785
PiperOrigin-RevId: 391368322
Originally we always set the outline provider of app bars to BOUND, even if the outline provider is set to none explicitly in the XML file.
Checks if the outline provider is set to BACKGROUND before we override it, to prevent unwanted overriding from happening.
Resolves https://github.com/material-components/material-components-android/issues/2332
PiperOrigin-RevId: 391339943
Previously the BottomSheetBehavior was checking the measured size during onLayout and if it exceeded the max width or height configured it would "adjust" them by directly modifying the width and height on the layout params and then posting a setLayoutParams. This has many problems and is fundamentally the wrong way to do it. First off, a view should never modify the layout params that are configured on it for two reasons, one, they are properties of the parent view group, not the view itself, and two, they are almost always intended for users of the view group to configure, not the view group itself. Modifying the layout params directly is clobbering any previously configured parameter and permanently changing the layout (for example consider the case where the max width is set to 100dp and then later set to 200dp, the view would not be allowed to grow to 200dp because its layout params would already have been clobbered). Secondly the post is a very bad way to apply this max, not only does it trigger an entire layout pass a second time but it does so after having completed the first layout pass so it will cause the bottom sheet to render at the original size and then the capped size, it's both inefficient and will cause user visible jank.
The correct way to apply a maximum width/height is to do it during layout by incorporating it into the measure specs that are passed to the child. This doesn't clobber any state that the user of the view configured (i.e. when the parent measure specs change, e.g. due to screen rotation, the views correctly relayout) and it avoids doing multiple layout passes, the child can measure itself to the correct size the first time.
PiperOrigin-RevId: 387379138
Helpful for the case where the Top App Bar text/icons are still visible underneath a transparent status bar, when the Top App Bar is scrolled up.
PiperOrigin-RevId: 384985602
When BottomSheetBehavior is set to not draggable, it's still forwarding touch event to ViewDragHelper, which causes ViewDragHelper changes its state to dragging although it's not really dragging. This causes bugs like if we change draggable to true during "no-effect" dragging, ViewDragHelper won't report the dragging state change because it thinks the state is not changing.
Fixes this by avoiding forwarding touch events to ViewDragHelper when it's not draggable, so its state won't be changed.
Resolves https://github.com/material-components/material-components-android/issues/2258
PiperOrigin-RevId: 384942764
We disabled ChipTouchHelper on purpose to workaround a Talkback issue but we didn't stop forwarding touch/hover events to ChipTouchHelper, which cause some Talkback logic work incorrectly on certain API levels.
Adds a state variable to avoid using ChipTouchHelper when it's not registered as accessibility delegate to solve the issue.
Resolves https://github.com/material-components/material-components-android/issues/2155
PiperOrigin-RevId: 383911836
