We set ?attr/colorControlHighlight as scroll indicators' background attribute. However, on older platforms this will crash the app due to Android expects a drawable or a plain color for the background attribute.
Changes the view to TextView so it will be rendered as MaterialTextView, which supports app:backgroundTint with CSLs. Also changes the base background color to #1F000000 and the tint color to ?attr/colorForeground, which are aligned with what framework's alert dialog implementation is doing.
Resolves https://github.com/material-components/material-components-android/issues/2455
PiperOrigin-RevId: 423917985
When scroll range changes, the current scroll position may not make sense anymore. Therefore we need to save the scroll state and restore it after the scroll range is invalidated. This change reuses and refactors the existing saving instance state logic to support this need. Also adds a flag to denote "fully expanded" state to avoid improper scroll position calculation when views are still being initialized.
PiperOrigin-RevId: 421348135
This CL fixes a couple of badge state related issues. First, it prevents the badges created before restoring instance states from being overwritten by the old instance states. Second, it makes badges reload their default style settings everytime when its being recreated so if the environment has been changed, the default values will reflect the environment change.
This CL also fixes that several attributes were not correctly saved/restored or their default values were not correctly loaded.
Resolves https://github.com/material-components/material-components-android/issues/2032
PiperOrigin-RevId: 420096508
1. Consolidates single selected ID and multiple selected IDs to a single selected
ID set.
2. Separates View states and internal checked states so we can focus and enforce
policies much easier on only internal states.
PiperOrigin-RevId: 420087718
The snack bar content layout is by default horizontal, and we only change it to vertical when the action view is too wide and ellipsizes the message text. Therefore if the layout orientation is already vertical, we should just keep the layout and no need to check if the message text is multi-line again.
Resolves https://github.com/material-components/material-components-android/issues/1876
PiperOrigin-RevId: 419885582
1. Consolidates single selected ID and multiple selected IDs to a single selected
ID set.
2. Separates View states and internal checked states so we can focus and enforce
policies much easier on only internal states.
Resolves https://github.com/material-components/material-components-android/issues/2263
PiperOrigin-RevId: 418054400
Changes are mostly to keep start/end layouts and icon views hidden (visibility = gone) when they are not needed.
Resolves https://github.com/material-components/material-components-android/pull/2326
GIT_ORIGIN_REV_ID=0393ac65d562bc87d340ec7bb260ebba99a1ac3b
Co-authored-by: leticiarossi <9288695+leticiarossi@users.noreply.github.com>
PiperOrigin-RevId: 418038435
The same remapping is done on API 21+ by framework base themes. On API levels lower than 21, AppCompat base themes "backport" the behavior to map window background to a separate color resources. With Material 3 we want a consistent and clear behavior, this CL explicitly remaps android:windowBackground to android:colorBackground so the behavior will be the same across all API levels.
PiperOrigin-RevId: 417711790
We missed to include top/bottom insets of button styles into dialog action margin calculation. Also the paddings between titles and messages were not correct.
PiperOrigin-RevId: 417626927
It seems like on Android 8 & 9 framework's View implementation has a bug that under certain scenarios if we set a view's visibility when view.getParent() is null, it can cause NPE crash.
Fixes this by switching the order of addView and setVisibility() call.
Resolves https://github.com/material-components/material-components-android/issues/917
PiperOrigin-RevId: 413978332
During a previous refactoring, the maxWidth enforcement logic was incorrectly moved to the inner layout of snackbar. Moves the logic back to the outer layout so it can be properly applied.
PiperOrigin-RevId: 413938993
Unlike other child views of AppBarLayout, CollapsingToolbarLayout will shift its top boundary to consume the window insets as well. Therefore we need to shift the top boundary back when calculating snapping positions to have a consistent logic with other views.
This CL also simplifies the calculation so the origin of the y-coordinate used in the calculation will always be the top of the AppBarLayout.
PiperOrigin-RevId: 413750156
