1. If the speak passwords settings is on, the accessibility events emitted from a
TextView should contain the text and before text of the source. The settings
shows the users consent to put the source's text in the event. While the code
that populates the current text in the accessibility event respects the
setting, the one that populates the before text does not. As a result the
fact that the user has typed a letter cannot be echoed by an accessibility
service.
bug:7468768
Change-Id: I7580c37936d742f42653315b2591e268a634d22b
The conversion of the error indication on Editor to RTL-aware was only
partially completed, and was causing bugs such as an error indication
failing to appear when set (bug 7457897).
This patch reverts these changes and just always sets the error drawable
on the right. This fixes the above bug, and also makes the error
drawable position always consistent with the error popup (before, in an
RTL layout direction, the popup would be on the right and the drawable
on the left).
Making the error display fully RTL-aware should be done as future work.
Change-Id: Icaee91210454ed9056e7200520d9275303de02ca
This new widget replaces DigitalClock. It listens to all the correct
system events and offer the ability to customize the formatting
patterns in 12-hour and 24-hour modes. It also supports fixed
time zones to create world clocks.
One more step towards becoming ClockOS!
Change-Id: I677e5dfca8cd8c8d1f8c49e54d7507f4d1885bf4
This reverts commit 6bf6eb7d5f.
and also fbc21e126f
I have also removed all unnecessary calls to resolveLayoutDirection(int). This is possible as
we are resolving layout params on every child of a ViewGroup as of commit
fcc3348f61
Change-Id: I262a375b03fcc3c9261cbe2edebb6ec42ec2e186
- check layout direction previous value in the onResolveDrawables(int) callback
- dont do any Drawables resolution if we cannot resolve the layout direction
- also remove unnecessary call to resolveRtlPropertiesIfNeeded() in ViewGroup when
adding a child as the call to resolveRtlPropertiesIfNeeded() will be done into
the measure() call itself later
Change-Id: I62237af3d307dfea203f7f2865551d1c61a0e0b8
- set the popup layout direction depending on the anchor view's layout direction
(if not defined before)
- make first pass of ViewRootImpl.performTraversals() and configuration update
not override any layout direction that could have been set before
Change-Id: I8e86ca805f0caf52c058d06aa7861df56fb862e6
- set the Configuration's layout direction in ViewRootImpl instead of PhoneWindow$DecorView
- then remove unecessary API on ListPopupWindow for passing the layout direction
Change-Id: Ia2c6e4aa8cb82aed9b088bc3b8004ea0a1ded1f3
When deferring scroll to a point, it's possible the text changed between
the time the scroll was requested to the time layout happens. In this
case, it attempts to scroll to a point past the end of the text buffer,
which created an infinite loop.
This patch clamps the scroll offset to the length of the text, so it
just scrolls to the end in that case, rather than crashing.
Change-Id: I53740d119d588560f5a4d9fb80e38f7057faab89
- make SeekBar follow layout direction changes
- also fix onSizeChanged() missing call to super class
Change-Id: Ide036e673c5f104b12e7321648ac027547e04065
The flickering was caused by trying to scroll to the cursor position
while the view was in an inconsistent state (text updated to change the
number of lines, but layout not done yet). This patch defers the actual
setting of the cursor until layout is done, when layout is pending.
Change-Id: I8ed3a402beb8058ac7a7f3935afeb946a23308ab
- do correct resolution and reset propagation for all RTL properties (padding and drawables included)
- fix CheckedTextView padding too
Change-Id: Ie603683a2324b2a6ef2c03633d01d5726c883b90
This reverts commit b49e4d63d1.
This produced problems with app compatibility. The boolean array
introduced in this patch is never resized and can cause applications
expecting different behavior to crash with index out of bounds
exceptions.
This looks like a good path but it will need to be revisted later.
Bug 7221618
- fix LayoutParams resolution for LinearLayout only
- apply onResolveLayoutDirection() in both measureHorizontal() and
measureVertical()
Change-Id: I5fcded9a79cd9aaeb0e12da7fd14176b71ba2fb6
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.
