The earlier patch 3cf7b3c59 introduced a stability regression. Perform
the appropriate bounds checking alongside the fix it implements.
Bug 8264185
Change-Id: I943d6c05bacdd777f89243fdac97788b16639dc6
- remove the ICU related methods and update the methods using the "reserved" argument
- update to CTS in another CL too
Change-Id: I5509736568c342d9d17bfeafc17951117ab5d3cc
- fix start/override mechanism
- take care of RTL compatibility mode (pre JB-MR1)
- fix where reset of drawables resolution needs to happen
Change-Id: I55a69487a0eedee14c4be7006ee0abad085200ad
This is the other part of a fix with transient state. A layout container
may be out of sync with its adapter during a data change. When the transient
state views are managed by their positions, and these positions may not match
between the container and the adapter, then the views will not be updated
correctly on the screen (though the underlying data will still be correct).
An earlier fix addressed the problem when the adapter has stable IDs (managing
the transient views by their IDs instead of their positions). This fix addresses
the other part of the problem, simply avoiding managing via positions during
a data change.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I0fe1692a1507a042180f8a14a8ef2d0c6946a061
ListView child views with transientState (setHasTransientState(true)) are not
handled correctly when the data set changes, such as when an item is added
or removed. The problem is that the transient views are cached by their
position, but this position is out of sync between the ListView and the adapter
until the ListView layout process is complete.
A better way, which unfortunately only works on ListViews with stable IDs, is
to cache the views by their itemID instead, and to use that ID to determine when
and where to reuse/retrieve a transient view during the ListView layout.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I2fc25e71ed6655af30b9c3f47fdf014e9b667616
Drawable has setAlpha(int), but no getAlpha() (although some subclasses have added the
method). This makes it more tedious to use the property. For example, animations that wish to
animate this property must explicitly give it a start value since this value cannot be queried
from the object.
The trick is that setAlpha(int) is abstract, only implemented by subclasses. We cannot take this
approach for getAlpha(), as we would break all subclasses of Drawable until they implemented the
method. Instead, we'll add a default method which returns an invalid value, making it easier for
clients of the method to detect whether the value is valid.
All subclasses of Drawble in frameworks have been changed to add an override of getAlpha() when
appropriate.
Issue #7485875 Drawables is missing getAlpha()
Change-Id: I06b6e35f1a56d202838eca44759c85c82595020a
Drawable has setAlpha(int), but no getAlpha() (although some subclasses have added the
method). This makes it more tedious to use the property. For example, animations that wish to
animate this property must explicitly give it a start value since this value cannot be queried
from the object.
The trick is that setAlpha(int) is abstract, only implemented by subclasses. We cannot take this
approach for getAlpha(), as we would break all subclasses of Drawable until they implemented the
method. Instead, we'll add a default method which returns an invalid value, making it easier for
clients of the method to detect whether the value is valid.
All subclasses of Drawble in frameworks have been changed to add an override of getAlpha() when
appropriate.
Issue #7485875 Drawables is missing getAlpha()
Change-Id: I3211bb03789282e010356bad92da0a4a9fe9afb3
If the calendar view of the date picker dialog is shown we
do not use a formatted date as the dialog title since the
calendar view shows it, instead we show a static "Set date"
title. However, the initial state of the date picker dialog
on a tablet has a formatted date since the date picker widget
does not do a correct check whether the calendar view is shown
which returns a false negative resulting in a title with a
formatted date being added since the dialog thinks it has no
calendar view.
Change-Id: Ibf4c433b34ab1ee1bc1dc386689664a32283fb6a
If the calendar view of the date picker dialog is shown we
do not use a formatted date as the dialog title since the
calendar view shows it, instead we show a static "Set date"
title. However, the initial state of the date picker dialog
on a tablet has a formatted date since the date picker widget
does not do a correct check whether the calendar view is shown
which returns a false negative resulting in a title with a
formatted date being added since the dialog thinks it has no
calendar view.
Change-Id: Ibf4c433b34ab1ee1bc1dc386689664a32283fb6a
This fixes a bug where secondary user widgets weren't being updated
properly because the system was checking for SYSTEM_UID which no
longer works with keyguard in a separate process. The symptom was an
app with a listview, like Gmail, would always show an empty list for
secondary users.
Change-Id: I3749a7a0b39f1eb7922966af0fbdcefdd804e41e
Call updateSelection in endBatchEdit instead of onDraw.
This works because all edits go through a batch edit,
which is already the case although the next change will
enforce it going forward.
This is step 3 of a four-step refactoring.
Bug: 8000119
Change-Id: Ia5e257382e2ef2168726bf3d9c7c84f9379ba376
When the selection is set via Selection#setSelection, the
Editor needs to know so that it can call back to a bound
IME, if any. This adds a watcher to catch these events.
This is step 2 of a four-step refactoring.
Bug: 8000119
Change-Id: Ia01aee853d5cafb4820fd234bc24b587ad3f7dd0
This is step 1 of a four-step change which will move where
updateSelection is called in regular text fields. The new
behavior will be to call it for each actual batch of
changes, instead of doing it in the render loop which leads
to both false positives and true negatives.
Bug: 8000119
Change-Id: I17bd91a129b18d5451fe1d8e7794ae20165de309
- instead of passing the screen size as a constant for computing the
layout size in RTL mode, we just use a real constant. Any value would
work actually, as soon as the value would not be null.
Change-Id: If9f5b38afa88938db36a795bfc8a403ad660726b
