NavigationView tries to determine if it is behind the status bar by checking if it's at the top of the screen. If it is and there are insets, it will draw a scrim. It also tries to determine if it is under the system nav. If it is and the system nav isn't fully transparent, it will also draw a scrim.
PiperOrigin-RevId: 264167166
Also updating clear text end icon to be not checkable, so that screen readers don't announce the icon's checked state as it's not relevant (differently from the password toggle icon, for example).
PiperOrigin-RevId: 259532643
Add a itemMaxLines attr to NavigationView and propagate it down to the internal CheckedTextView.
Also, make a slight change to design_navigation_item.xml layout to accommodate multiple lines of text. Without the layout change, the layout_height of the item is set to "?attr/listPreferredItemHeightSmall" so it can't contain an arbitrary number of lines. It can also chop lines in the middle.
To fix this, we change layout_height to "wrap_content" and add a minHeight attribute set to "?attr/listPreferredItemHeightSmall". This results in the same behavior for single line items but expands appropriately to contain items with multiple rows.
PiperOrigin-RevId: 242858439
The annotation was only necessary for the method in TextInputLayout that calls CollapsingTextHelper#getCurrentCollapsedTextColor.
PiperOrigin-RevId: 230616582
- Fixes materialThemeOverlay case where client is not using our theme or style (e.g., AppCompat + component with no style set)
- Also refactors createThemedContext() to use obtainStyledAttributes with defStyleAttr and defStyleRes instead of getTheme().resolveAttribute()
PiperOrigin-RevId: 213464594
This removes duplication between the 2 implementations and automatically fixes font loading bug in CollapsingToolbarLayout & TextInputLayout. It has a side effect of changing font loading from sync to async but it shouldn't affect anyone since font loading wasn't really working in the first place. It may affect the UIs that were affected by the original bug though.
To alleviate possible "font flickering" due to async loading, CollapsingTextHelper defers the TextPaint changes until the font is actually loaded.
Another scenario the async loading would have an impact on is when the font is manually overwritten with CollapsingTextHelper.setTypeface() while async op is still ongoing. The result of async load would then overwrite the font back to the originally requested. This happens in TextInputLayout which overwrites its own font setting to this of its child whenever its added. This may happen before async op completes. To guard against that, any direct font setting automatically cancels the async load (cancels == ignores the result when it comes).
PiperOrigin-RevId: 212328671
