Bugs 6075823, 6050563
Revise pressed state dispatch logic:
Only propagate pressed state to non-clickable views. This should
eliminate the "double glow" problem in some list items where a
clickable child button has a secondary glow along with a clickable
parent. This only applies to setPressed(true) calls; setPressed(false)
must propagate. Don't early-out in setPressed to support this use
case.
Change-Id: Ibbe2309f5030282fad8d23e4a9bc4616b3f5dc7c
Optional titles will only be displayed in the CAB if they entirely fit
instead of ellipsizing.
Fixes bug 5821883
Change-Id: I0cfd6d4fd34a4fa9f520499d577706da30606811
As said in https://android-git.corp.google.com/g/#/c/155992
finishComposingText is indeed too broad of a method.
Introducing a new dedicated method to warn the InputConnection.
Should solve the problems with a negative counter value.
Change-Id: I5525d776916f0c42d5e6d4a4282aed590d7f0e9a
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
1. A bad merge on my part caused ViewRootImpl not to register
for accessibility state change.
bug:6064348
Change-Id: Idf7b8b444e9021e9d9ec3749164cfe448c8268ab
1. AccessibilityNodeInfo were not cloned when cached
and obtained from the cache. This was causing a
problem when the client calls #recycle() as he
should since this results in wiping the data of
the cached node info.
bug:6026952
Change-Id: I5807b09d95ef6f310327192ff91f036adf337e33
1. Before there were two caches one in the app process that
kept track only the ids of infos that were given to a
querying client and one in the querying client that
holds the infos. This design requires precise sync
between the caches. Doing that is somehow complicated
since the app has cache for each window and it has
to intercept all accessibility events from that window
to manage the cache. Each app has to have a cache for
each querying client. This approach would guarantee that
no infos are fetched twice but due to its stateful nature
and the two caches is tricky to implement and adds
unnecessary complexity. Now there is only one cache in
the client and the apps are stateless. The client is
passing flags to the app that are a clue what nodes to
prefetch. This approach may occasionally fetch a node
twice but it is considerably simpler and stateless
from the app perspective - there is only one cache.
Fetching a node more than once does not cause much
overhead compared to the IPC.
Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
1. For accessibility purposes View may report a virtual tree
rooted at them to convey the logical structure they draw.
These are usually custom Views. Such views cannot have
children and this patch adds a check for that.
bug:6022217
Change-Id: I3795a613b4aef1a7ec5810db8584a11b648870f2
1. UiTestAutomationBridge was accessing the root node in the
active window by tracking the accessibility event stream
and keeping the last active window changing event. Now
the bridge is stateless and the root node is fetched by
passing special window and view id with the request to
the system.
2. AccessibilityNodeInfos that are cached were not finished,
i.e. not sealed, causing exception when trying to access
their children or rpedecessors.
3. AccessibilityManagerService was not properly restoring its
state after the UI automation bridge disconnects from it.
I particular the devices was still in explore by touch mode
event if no services are enabled and the sutomation bridge
is disconnected.
4. ViewRootImpl for the focused window now fires accessibility
events when accessibility is enabled to allow accessibility
services to determine the current user location.
5. Several missing null checks in ViewRootImpl are fixed since
there were scenraios in which a NPE can occur.
6. Update the internal window content querying tests.
7. ViewRootImpl was firing one extra focus event.
bug:6009813
bug:6026952
Change-Id: Ib2e058d64538ecc268f9ef7a8f36ead047868a05
This allows apps to override setPressed to reliably observe changes in
pressed state for custom views.
Change-Id: I59f472a9d864f4abcc4f692fef0a13f004348432
I had submitted the patch about this issue at
https://android-review.googlesource.com/#/c/20438/ before. But it
has never been included in any version.
In the latest implementation, touchSlop is a configurable value
which is declared in config.xml for each device. First of all,
the problem is that BiggerTouchSlop is not scalable and variable
value according to a configured touchSlop.
I don't think that there should be a new api in ViewConfiguration
for this. Because the bigger touch slop is a local threshold value
in GestureDetector. The only thing to be satisfied is that the
value should be bigger than configured touch slop and should not
be over double touch slop.
Change-Id: I2c6662400fcffb4a7192ede4ac8da08559aa7948
Transient state is temporary bookkeeping that Views need to perform
that the app should not need to be aware of. Examples include text
selection regions and animation state.
Transient state is a problem for AdapterViews like ListView that do
view recycling. Unless the app takes responsibility for tracking and
restoring transient state as if it were a part of the adapter's data
set, it cannot correctly recycle views. Selections disappear when an
EditText is scrolled out of sight and animations seem to play on the
wrong views.
Views can now flag themselves as having transient state. (As the name
implies, this should be a temporary condition.) If a ViewGroup
contains a child with transient state, that ViewGroup also has
transient state.
AbsListView's recycler now tracks views with transient state
separately. Views with transient state will be retained, and until a
data set change occurs the same view will be reused for that position
instead of calling the adapter's getView() method.
The API to set and check transient state is currently hidden.
Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
This optimization allows us to quickly skip operations that lie
entirely outside of the known bounds of a display list. Because
of ViewGroup.setClipChildren, we must keep the operations recorded
in the display list. setClipChildren(false) is however a very
uncommon operation and we will therefore often benefit from this
new optimization.
Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
Set a barrier on traversals.
Vsync is still not enabled by default in this patch so there
should be no observable effect from these changes.
Change-Id: Ie12081b95a8f1e81ed686edf747cc62f2e044b7e
