The first way I had it produces somewhat unexpected behavior. If you
scroll past the top of the list, focus moves down to the control
below.
This changes it so scrolling past the bottom of the list moves focus
to the next control below.
Change-Id: I886e1854df85ceb203dac61c7f8c7daf6749e90e
Earlier patch reversed a few lines of code that allowed deselection of
the currently selected item in CHOICE_MODE_SINGLE. Put it back the way
it was.
Bug 7289436
Change-Id: Ia1c5f3238d2faa3dd79e474851333fda90978d3c
PopupWindow already tracks when anchor views scroll, but it doesn't
catch other layout changes.
Bug 7267264
Change-Id: I1e20f9335057832c78c3002aa931f533dd77514b
When breaking a line, the paragraphs below the new line break were still
being drawn in their old location. This only happened when the height
was fill_parent, otherwise the height change would force a relayout,
which in turn would do a full invalidation.
This patch checks for changes to the layout height (not just the widget
height, which won't change when it's fill_parent), and invalidates.
Change-Id: I64adb9f5eae0479c1c9c8d37c10c2c27a6f582a8
This regression has been introduced by this Change: Ia846de16bbc54f0729608259aa4b530da9404245
- in CHOICE_MODE_SINGLE you need to clear the checked states before doing anything
- rename variables for better readability too
Change-Id: I89b4390e5ebb192ca280fea2c06f991b537a2870
MeasureSpec.makeMeasureSpec has a bug where a negative or very large
size parameter will cause the resulting MeasureSpec value to
overflow. RelativeLayout partially relies on this when measuring
children with mode UNSPECIFIED; a default value of -1 in a local
variable ends up being passed to makeMeasureSpec, overflowing a mode
value to create a measurespec that is very large in size, with AT_MOST
as the mode. The correct behavior is for RelativeLayout to propagate
the UNSPECIFIED mode.
Unfortunately a number of custom view implementations in apps rely on
the buggy behavior as they do not implement their own onMeasure
method. This makes them fall back to View's default onMeasure
implementation, which accepts the spec's size unconditionally for
AT_MOST or EXACTLY modes, but falls back on
getSuggestedMinimum[Width|Height] for UNSPECIFIED. If the view had no
background drawable with dimensions and no minWidth field set, this
fix for RelativeLayout causes some views to measure with a size of 0
rather than a size of the 30-bit version of 0xFF...
Revert these fixes in the interests of compatibility. The next version
will conditionally use the new behavior if targetSdk > JB-MR1.
This also required reverting a fix for ImageView's adjustViewBounds
functionality, as it cannot be implemented reliably if this
RelativeLayout fix is not also in place.
Revert "Fix UNSPECIFIED measurement in RelativeLayout"
This reverts commit 132a742b94.
Revert "Fix adjustViewBounds handling for ImageView"
This reverts commit d5edc77217.
- do not need those variables. Use what we already have in View.
- reset padding to initial values before changing it.
Change-Id: Ib396b3dca6e98a94d83a538a9b594b5eb426c453
When computing the adjusted view bounds, don't constrain the
dimensions by the original estimate if the opposite dimension has a
fixed size. This can result in the view never getting properly
enlarged.
Also fix a long-standing bug in MeasureSpec.makeMeasureSpec where
oversized or negative values could result in broken packed values.
Bug 7240251
Change-Id: I359d108ff52b6f3b5c4bf393d2271d28999c0127
When apps request layouts while scrolling is in progress, Gallery
children can get offset in strange ways. Compensate for this by
tracking the last known offset and applying it during layout.
Bug 7245853
Change-Id: I9d746ae6bb06918e2d920c58052f72e749a7ffbf
1. The BumberPicker exposes APIs for settings displayed values for the
selected numbers. If the min and max value of the picker are less then
the length of the new displayed values array, i.e. they are out of
bounds, the NumberPicker crashes.
bug:7254000
Change-Id: I182e30216ef28c98d6541f9c985b43c8179dec76
