* commit '34bc73dff1f0c8402da3fc9bd1f0175bddcaa842':
Revert "Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter"
Bug #8725945
Selecting text in an EditText causes the View to have transient
state. This would in turn cause the View to be removed from its
ListView parent. When removed, the EditText would lose its
AttachInfo, causing all sorts of problems. Headers and footers
must not be removed, only detached. This is the part of the fix
in AbsListView.
Fixing AbsListView triggered a second bug: when a View is removed
from the Window manager, it would keep its parent assigned, thus
making it impossible to add it again to the window manager. When
a ViewRootImpl goes through doDie(), it must set its content view's
parent to null to properly cleanup.
Change-Id: I0489daa74f8f7fcf85526f0928f8925ec30d4f42
The calendar view was updating its header only if the focused
month changes. Removed the check whether the displayed month
changed before setting it since the setter is carefully called
only in cases when there is a change. Hence, now if the year
or the month change, we update the header. This is the safest
and least intrusive fix.
bug:9167305
Change-Id: I98200bb57580f6416abd30c6c25454d4474add64
The node bounds populated by the child TextView were not consistent
with the bounds manually populated for its parent NumberPicker.
Bug: 9072003
Change-Id: Icbfa64f52cf11fd39c7243936227b8ba36280c3c
We are prefetching accessibility node infos to minimize the number of IPC
calls when an accessibility service introspects the screen. It is however,
possible that the view we are prefetching is a child of an AbsListView whose
adapter changed its data but the AbsListView still did not perform a layout
pass to sync its children with the new adapter state. This may lead to an
exeption when trying to query for the state of a child's position. If the
data of the adapter is changed and the layout pass still not performed,
we return null for the AbsLIstView's children. When the layout pass
completes we already notify the accessibliity layer so it will be able to
refetch the children of the AbsListView.
bug:8433433
Change-Id: I56313c721aef3848b15fad50027d068ba1d291f7
- add missing assignment for text direction (mTextDir)
- when layout direction change, update text direction (mTextDir again)
Change-Id: Id600fb0c5897a0d2ee5f9fe18a63437dc3e528d9
We added APIs to allow an accessibility service to extend the
selection while moving the cursor at a given granularity such
as word, character, etc. The problem is that the traversal was
extending only the end of the selection while moving forward
and the start of the selection while moving backward. This leads
to a case in which the user cannot shrink/extend the selection
because for example instead of shrinking the end of the selection
the implementation was extending the start.
Now extending the selection moves only the selection end. This is
the same behavior as text view using a keyboard.
Tests: https://googleplex-android-review.googlesource.com/#/c/307062
bug:8839844
Change-Id: Id6965b102647df909f61301fcc8ec05458dd5881
This lets apps get the audio session id of the video being played, so
they can apply effects to the audio track.
b/8767565
Change-Id: Iaa39d97d0b6fb528ed04b52d579afa58444ebcfe
AbsListView is backed by an adapter. After the adapter data changes
the view sets a flag that its state is dirty and requests a layout.
If an accessibility service asks for the state of a list item at
this point, it may incur an error since the views and the adapter
are not in sync.
Now if an accessibility service queries for a list item when the
data set is changed and the item views are dirty, we pretend the
children do not exist. After the layout happens, we notify the
accessibility layer that the screen content changed so it can
refetch the views if desired (this notification mechanism is
already in place in AbsListView#handleDataChanged()).
bug:8433433
Change-Id: I4287a0ac2ef6bb33f1f988d5ddad973556c305ca
Before, we'd have something like 2006 4月12. After, we have 2006 4 12.
The alternative would require using custom NumberPicker.Formatter instances
for the year and day fields in these locales, and that seems significantly
more disruptive.
Bug: 8766552
Change-Id: I568578aae2f80f2acfc53cd277ef3beae6743472
When accessing an invalid entry of the list, an IndexOutOfBounds exception is thrown, not an ArrayIndexOutOfBounds exception.
Change-Id: I3cf59faab004fa6391d84f30f280e0c9bd92dc44
Signed-off-by: Taylor H. Perkins <taylorhp@gmail.com>
DatePicker always effectively uses yyyy MMM dd, so we need to ask
icu4c what order those should appear in for the user's locale. The
existing DateFormat code was an approximation that worked for en_US
but not for all languages (fa being one example).
Bug: 7207103
Change-Id: I7b12568dbc02522ebad6e1db5f8426109cd6f7ce
1. UiAutomation#executeAndWaitForEvent method was invoking the passed
runnable while holding the lock which may lead to a deadlock. For
example: a runnable that calls getActivity() gets us into a state
like this.
2. UI automation services did not get all capabilities such a
service can have. Now a UI test service gets all of them.
3. When UiAutomation was exiting for event fired as a result of a
performed action, it was checking whether the received evnet time
is strictly before the time of executing the command that should
fire the event. However, if the execution is fast enough, i.e.
less than one millisecond, then the event time and the execution
time are the same. This was leading to a missed signal in rare
cases.
4. AccessibilityNodeInfoCache was not clearing the relevant state
for accessibility focus clearing event.
5. Accessibility text traversal in TextView was partially using text
and partially content description - broken. Now we are using the
text since for text view and content desc for other views. In other
words, we are using the most precise text we have.
6. AccessibilityManagerService was not granting capabilities of a
UiAutomation service - plainly wrong.
CTS change:https://googleplex-android-review.googlesource.com/#/c/300693/
bug:8695422
bug:8657560
Change-Id: I9afc5c3c69eb51f1c01930959232f44681b15e86
The fix in:
https://googleplex-android-review.googlesource.com/#/c/300346/
worked but the constant used had an extra trailing zero - which was confusing
and put a 1 in the 'flag' space of the measurement spec.
The intended number was:
0x00800000
Unfortunately, this intended constant doesn't fix this bug.
The constant submitted in this fix is:
0x00010000
which is outside the 'flag' space of measurement specs and appears to steer clear of overflow
problems in the scenario of this bug.
As suggested in the submission above, it would be preferable to rework of the RTL code to avoid
the use of such a constant as it seems very unlikely indeed that any choice of integer can
avoid problems in all cases.
Change-Id: I0c6744257ef2aebe8dbc8c041a447f9b90ee4b84
GridLayout is working as intended here. The bug is appears to be in RelativeLayout
(and possibly LinearLayout).
The value of RelativeLayout.DEFAULT_WIDTH = Integer.MAX_VALUE/2 is 0x3FFFFFFF has bits
set in the range that is used to flag certain conditions and states by the layout system.
In View we have:
MEASURED_SIZE_MASK = 0x00ffffff
MEASURED_STATE_MASK = 0xff000000;
MEASURED_STATE_TOO_SMALL = 0x01000000
This change fixes this bug, though it looks as if that a safer solution would be to not introduce
this constant and code path in the first place - as RelativeLayout's measurement algorithm operates
in the LTR case without it.
Change-Id: I01c51ae854620f08dd63047594486a3464c86f3a
The rendering code optimizes by rejecting drawing operations that
lie outside of the bounds of their views. This works in most
situations, but breaks down when containers have called
setClipChildren(false), because we reject drawing that is outside
of that container, but which should be drawn anyway.
Fix is to pass in the value of that flag to the DisplayList drawing
routines which take that flag into account when deciding whether
to quickReject any particular operation.
Issue #8659277 animation clipping
Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
