Adding the a11y delegate and a11y actions was dependent on there being a CoordinatorLayout child that both inherits from certain scrolling classes (NestedScrollingChild, ListView, ScrollView) and has an AppBarLayout scrolling behavior. This was too restrictive and so we only check for a behavior.
Any scrolling child may add an a11y delegate or scroll action to the parent CoordinatorLayout.
PiperOrigin-RevId: 448335380
Ensure the CoL can scroll to the bottommost elements of the scrolling child, which may not be visible due to the app bar.
Also, set the node info properties to expose the CoL to auto-scrolling.
PiperOrigin-RevId: 447596411
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 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
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
In the snap logic we didn't take the AppBarLayout's top padding into account, therefore in certain cases the scrolling will be incorrectly snapped to the top of CollapsingToolbarLayout instead of the bottom of it, which cause the title not collapsed.
PiperOrigin-RevId: 400749401
An app bar remembers the visible percentage of its first visible child during recreation to restore its scroll position. However, if an app bar is "fully" scrolled (scrolled to its maximum range), gets recreated, and changes its size after recreation, it can become not fully scrolled even if it keeps the same visible percentage of its first visible child, due to the difference in its own size. This can result in unexpected "gaps" in the layout due to inconsistency between AppBar layout's scroll position and the content view's.
Fixes this by remembering the "fully scrolled" state and restore it during recreation.
PiperOrigin-RevId: 398013525
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
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
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
