Applying same method to insertion cursor as the text selection drag
handles to improve moving along lines.
Basically adds some slop above / below the current line and only
allows you to change lines if you move outside of that.
Bug: 21306433
Change-Id: I6c7f3a496fbd1ea66936832f96325736cea872aa
It's pretty easy to accidentally move to a different line when
selecting text. This CL makes an adjustment so that if the user
is on a line, they must move above the top of it + slop to move
up a line, and they must move below the bottom of it + slop to move
down a line. This applies the changes to the drag accelerator.
This CL also makes an adjustment to not apply the finger offset
to the drag accelerator until the user has moved lines, this was
causing an issue where it would immediately include the above line
when initiating the selection.
Bug: 21306433
Bug: 21303943
Change-Id: Id240136493f62524fe6445d8bd65479084fe8126
It's pretty easy to accidentally move to a different line when
selecting text. This CL makes an adjustment so that if the user
is on a line, they must move above the top of it + slop to move
up a line, and they must move below the bottom of it + slop to move
down a line.
This CL also makes a small modification to check if the layout is
null and return early which simplifies some of the following code.
Bug: 21306433
Change-Id: I4a854e644faafaf1e159201ae1f2838862f16b25
The metadata local copy was mutated (swapped) to an empty copy after use,
we need make a copy every time.
Bug: 21442271
Change-Id: I8a71663ba964288bdd1d7f50b42db762d28d89c0
This is a follow up CL for Ifd05565ac0c057c46ec88a3fb9094c04934041d.
SpellCheckerSessionListenerImpl.taskToString(TASK_CANCEL) has
somehow returned "STATE_WAIT_CONNECTION" probably because of
a copy-and-paste mistake.
With this CL, it now returns "TASK_CANCEL", which is observable
only in debug log anyway though.
Bug: 21319642
Change-Id: Ib0bf11494bd3f210e6e8192fc25a33c65f7d313d
ViewGroup overrides class name population to
AccessibilityEvent. So className is always ViewGroup
for any ViewGroup inherited classes
b/21369265
Change-Id: I46095c21e523e05066c7f6ee395171d4725983ac
-Flicker was a side effect the delay in hiding the toolbar when
there is a down press on a TextView handle. The timing clashed
with the time it takes for the FloatingActionMode to release a
hide lock on a changing content rect. Extra flickers also happened
if the ActionMode happened to be invalidated at about the same time.
Since there was no longer a hide lock, the toolbar refreshed, getting
rid of the "Select all" menu item.
FIX. I believe we don't need the delayed hide on down press on a
TextView handle. I've removed this.
-I've also updated FloatingActionMode to ensure that hide locks
overlap one another if necessary. The toolbar can only be visible if
all locks are off.
Bug: 21793687
Change-Id: I290ea45ab17d5862b453cb319afb4c8ffe084cd0
This change adds three new timeslices :
- PostFork : As soon as possible after the app forks from the
zygote. Can be used in conjunction with the system_server
"Start proc:" event to derive an upper bound on fork() and
zygote overhead.
- RuntimeInit & ActivityThreadMain for ZygoteInit#runtimeInit
and ActivityThread#main.
ActivityThread#handleBindApplication and higher level functions
are already well instrumented in systrace. handleBindApplication
should occur immediately after ActivityThread#main.
Note that we use the Activity manager tag to make it easier to
correlate these new events with surrounding events (Start proc
and handleBindApplication) that are already using the AM tag.
bug: 21632700
Change-Id: Ibc01f1721f962c913f3c02a51763b6feb1eb6a4d
