1. Making sure that the comment blocks for methods setting/getting
resource attributes include links to the related attribute
documentation.
bug:6442803
Change-Id: If8acedfedf02400eee3f61ca3029325c05a5fb86
Bug 6442795
When the measureWithLargestChild setting is enabled, LL used to
measure the full container taking the largest child rule into account,
but the child views were not properly remeasured for AT_MOST
measurespecs. Correct this.
Fix measureWithLargestChild for height
Change-Id: Ieb91114bc2ae65f9104337bd6d16a7d9e559571d
Bug 6429006
Disallow intercepting touch events for parents of
ScrollView/HorizontalScrollView when scrolling begins. Properly
respect touch slop when the child of a ScrollView does not accept
touch events.
Change-Id: I2ce503ad5104d450829ed58cd2748c9163e020d3
This reverts commit 8a36e05443 which was causing
keyguard_screen_tab_unlock.xml to have a bad layout.
Change-Id: I50bdc6dbdf8d7b98ef77eae532860d375574213e
Bug 6378843
Corrects CL 183460, which would clip text with a width greater than
twice the TextView's width.
Internal horizontal translation is now handled in a similar way to
vertical scrolling.
Internal scrolling is indeed handled by the TextView, which translates
the canvas and sets the clipping bounds accordingly.
When drawing the internal DL, we tighten the horizontal bounds like we
did for the vertical bounds using top and bottom. As in Touch.java, we
use the getHorizontallyScrolling() method to know if we indeed have to
measure the actual text width. If there is no horizontal scrolling we
use the TextView's width as a safe upper estimate in order to avoid an
actual computation. Note that horizontal scrolling is typically only
used for long single-lined text, so that the measurement loop is quick.
As a result, the internal DLs represent the entire text, and there is no
need to invalidate them when an internal scrolling takes place. This
behavior replaces the draw-only-what-is-needed we had before, but is
more consistent with what we do for long texts inside of a ScrollView
with no noticeable performance change, even on very long text.
Change-Id: I47c24c0ae988547d4f1e9f87d136225c93a3056d
Bug 6404882.
When a cell has an unspecified row and a column that is specified as greater
than the specified number of columns, GridLayout fails to report or correct
the error and loops indefinitely searching for a valid row to place the cell.
There is a cyclic dependency between the validation of layout parameters
(and allocation of undefined cell indexes) and the maximum column/row counts.
A performance optimization in layout paramter allocation caused this dependency
to be handled in correctly. The problem is fixed in this CL for this bug and
the symmetric problem for rows.
Change-Id: I0392343bc8a721a0ca7163f58f233ba8046c22e2
Bug 2597058
ListView's touch scrolling can query the adapter for new views. As we now
flush pending touch events before running layout/draw traversals (when we
normally bring ListView back in sync), this can now happen more often.
Resync data before executing a scroll if a data set change is pending.
Change-Id: I3e4eba4c2537911ba9cb3393ee4d9e68e46f84bb
1. Make the feature opt-in (ViewGroup::layoutMode defaults to CLIP_BOUNDS) without inheritance.
2. Rename COMPONENT_BOUNDS to CLIP_BOUNDS.
3. Rename LAYOUT_BOUNDS to OPTICAL_BOUNDS.
4. Complete GridLayout implementation.
5. Change the default_gap between components to 8dp, to align with the Style Guide.
Change-Id: I8d40dfc5f4ca469f6424eb3ff60d07bec56e3a9f
