- as we remove the 9 patch padding trick, we need also to do the correct
positioning of the radio / checkbox / star during draw
Change-Id: I02b67bef9c0f2dc1c0c65361de14ab20ce9b881d
* commit '1586168302f79d10e85a5aeed7b486c4244cc98e':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit 'e9812bae0e0ce08bd232dc2371fdb959e4f7a318':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
- keep the Error Drawable infos into the Drawables cache
- reset left/right Drawable state before resolving where to put the Error Drawable
- get the mirrored Drawable for the Error popup background
- set the Error popup position depending on the layout direction (so that the "triangle"
of the background is pointing to the middle of the Error icon)
One restriction: we load the Error popup background Drawable corresponding to the layout
direction of the System Locale. So if you set the Layout direction on a TextView (or
an EditText) to RTL and set an error to it when you are in a RTL System Locale, then you
see that the background "triangle" is not pointing to the Error icon. This is working as
intended as the AssetManager load the Drawable resource depending on the configuration
which is in that case the RTL one thus loading the RTL version of the background (and not
the LTR one).
Thus there can be a discrepancy between the "layout direction" of the TextView
and the one from the Error popup background. This would happen only thru using the SDK and
not in a normal case when running an App.
Change-Id: I91bbfbe46ac20efe0e585c5d4c766db23b5c709d
Bug #7489774
This change also fixes a crash if you programmatically set the time
formats from code before the widget is attached to the window.
Change-Id: I73ead93f5866d9059a4b3823c4304aeca8e419b6
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
* commit '68b14054b96571d4009c6c5a9b4c3413d908a523':
Revert "Fix bug #7325234 LayoutParams are not resolved correctly (Settings apps looks broken on Manta in Arabic)"
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
* commit '09a5321c60c02d944684abb98e0daec9dd810fab':
Revert "Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.""
- 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
* commit '871a6d7d4fb3bffaff37e45f0b4f5e3c862239d2':
Revert "This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height."
* commit '4db3165793a837ffc8197184fbc13ef2217e3dfc':
This restores JB MR0 behavior where the framework throws an exception for improper layouts that are missing layout_width and/or layout_height.
