Previously any fontFamily value on a TextView would override a typeface
value, even if the fontFamily is from a TextAppearance (for example,
from the theme) and the typeface is explicitly set. This patch changes
the resolution order to fontFamily set directly on the TextView,
typeface set directly on the TextView, fontFamily from TextAppearance,
typeface from TextAppearance.
Bug: 16154223
Change-Id: I45c1e511fba8f64eb236200e3fa2e885c02b59dc
Also prevents the selector from jumping between the inner and outer
circle during touch exploration in 24-hour mode.
Bug: 19101918
Change-Id: If342056b378927397f8651dad5e8d806bcda03a6
Avoids unnecessary changes to pressed state. Ensures hotspot propagates
to both the list view and the list item view since both receive the
pressed state.
Bug: 19134424
Change-Id: If2496ce2042e43fe1c1efd527eeca10dc53e1f4a
To click a view we were computing a click location by ignoring overlapping
views that are actionable. However, detection whether a view is actionable
is not always possible as the view may handle touch events directly. This
leads to unhandled edge cases. We are taking a conservative approach and
ignore all overlapping siblings regardless if clickable. This is also has
limitations but hopefully less frequent edge cases.
bug:18889611
Change-Id: Icea0b7b3e2d4ed53e50e01cb6a99b880be560b14
automerge: 6e9f276
* commit '6e9f276ff1554b59692a1820f60217307460308b':
Accessibilty: Cannot click on views in a scrollable container covered by the toolbar.
In accessibility mode we calculate a point where to click in the accessibility
focused view as a bridge-gap solution before switching to accessibility click
actions. We cannot detect whether a view is covered by another one that consumes
all touch events, and therefore we may click on the wrong target. This was the
case with the toolbar. As a result a partially scrolled view in a scrollable
container covered by a toolbar cannot be activated and this is not an edge case.
bug:18986806
Change-Id: Ib41470c39806cec13e9b00b319879cd7f3412ab5
A previous change (df68999dc7) adjusted
the clipRect slightly on the right side, but didn't adjust the
padding offset used in fading.
Bug: 18820846
Change-Id: I68c0918f914742d1e7b91f9ea8d5acbd41938233
Also cleans up code a little to prevent unnecessary re-computation
of lower-cased strings and use final where possible.
BUG: 18874813
Change-Id: I852eb7a281aed64ac36e95f32f5fa410f50abfa4
The original change wasn't properly merged into lmp-mr1-dev because of
merge conflicts. This change manually resolves the conflicts. The main
reason for the conflict was that TimePickerSpinnerDelegate was swapped
with TimePickerClockDelegate.
This change also fixes the typo in the original change which was fixed
in a subsequent change.
Original commit: 12b6d29b7b
fix for typo: cb09bc45c5
Change-Id: I50bf8c2d86318f632465a38adfad16d1382a9319
Issue #18784539 Row stays highlighted if I begin scrolling after the rows been highlighted in "About phone"
Change-Id: Ia91467d8fe64eec077f20af70eae0d5bb070c255
Delegation is broken for widgets, but this fixes the most egregious issue
where TextViews that are top-level list items weren't handling CLICK
actions correctly. This will still need work, since now the focus action
won't run, but it's an improvement.
BUG: 18736135
Change-Id: I808ef628198946cc87f13c53d6245cd162a1e517
Overrides click action description for TimePicker hour/minute selectors
and manually specifies traversal order for radial time picker nodes.
BUG: 17468036
Change-Id: I4472b42a95d762085d7a4d382feb2b9216c0d41c
If autoAdvance is set, we need to always fire the listener. We should
create a separate callback for auto-advance, but this is a minimal fix.
BUG: 18654878
Change-Id: Ie7b8a3ff91761325a508f580b27fa3b08f7b4e16
There was a weird disconnect between setPressed() and hotspot propagation
behavior. This makes hotspot propagation work like setPressed(). Also
fixes ripple animation during drag-to-open.
BUG: 18631557
BUG: 18593243
Change-Id: Id4adf5d815e4d426b4182aac4d0c780f04472ae4
In accessibility mode we send down and up events activate a view. We will later
switch to accessibility actions but for now as a bridge-gap we compute a point on
the screen where to click for activating the view. The heuristic we use has edge
cases such as a view that handles all touch events but does not have any listeners.
In this case we do not ignore the target view's area covered by a view that handles
all touch events. As a result we click on the wrong target. While we cannot solve
this generically, in the case of standard components such as HorizontalScrollView
we can.
bug:18612258
Change-Id: If8482aac0d0ea53c5c90367d099d1b8d3a4559ed
