Also ignore the requestedPermissionFlags of yet to be installed
packages when trying to determine if a permission is new.
Bug: 22229417
Change-Id: I59d579cdc42d64bcfdefdb06e1576959355bb7a4
In extract mode, on every screen touch
TextView#setExtractedText gets called which calls
SpannableStringBuilder#sendTextChanged which in turn stops
the action mode. As a fix, if the text is the same only
copy the spans without replacing everything.
Bug: 22315095
Change-Id: I28da760b3dc11e1cfbaf720e547bd817c5b89d7e
Previously touch slop for line movement was based on the line position
of the HandleView, not the previous line touched.
Thai and CJK languages don't have a space at the end of a line so
the handle jumps to the beginning of the next line. This meant that
when calculating the touch slop it'd be from the incorrect line.
This CL tracks the previous line touched and uses that instead to
calculate touch slop and applies it to the selection and insertion
handles.
Note this is *not* added to the drag accelerator because
it does not have the problem of the handle jumping to the next line
since it has no handles.
Bug: 21925162
Change-Id: If4b231725c06489ec780a5b5a308ceffee804c20
Bug 22403868
Initial attempt only helped if setImageBitmap() was the only
thing called but during new-loading content it's common for a
placeholder to be set via setImageDrawable.
Tweak ImageView slightly to just have a BitmapDrawable that it
lazy-creates but will hold on to for any subsequent calls
to setImageBitmap
Change-Id: I7380521c7b363d458e4cda041f1f8b2b1fb3a93a
Bug: 22289362
It's pretty common for ImageView#setBitmap to be called
repeatedly. Avoid re-creating the BitmapDrawable in this scenario
as that has high object churn of semi-expensive objects like
Paint.
Change-Id: Ib77719cd0366d02c1a42f774850bf3b9caa9c288
Touch slop is from the bottom (or top) of the line + line height / 2.
It only makes sense to apply touch slop if the user is within a line
from the previous line. Additionally, not doing this can cause some
undesirable behavior if the user moves very quickly and the selection
catches up with a weird line by line selection increase, potentially
even having the selection be stalled until a next move event.
This CL alters the logic so that if the user isn't within one line
of the previous selection, it'll just use whatever line the user is
currently on.
Bug: 22385003
Change-Id: I4f37988893868e5e2b7925314fe824c3da9c1b97
Per Chris, the existing doc was incorrect: you *can't* check for a
button press and a switch flip the same way. (The button triggers a
click event, but the switch does not.) Chris suggested that we just
remove the reference to onClick and suggest using a listener for
both kinds of buttons (ToggleButton and Switch).
Also pulled one note out of a section where it didn't fit (the bit
about changing a button/switch's state programmatically didn't have
much to do with listening for clicks) and put it at the top, and I
fixed a Javadoc typo for a relevant class that I happened to notice.
See first comment for doc stage location.
bug: 20625504
Change-Id: I9c8975111381e5b169f6a61454ef3a93da635759
- mouse hover moves the selected item in the menu. It moves
the selection rectangle, and further up/down key or enter
key will start from the hovered item.
- when the mouse exits from the entire popup window, the
selection is canceled. Further up/down key will start from
the first item.
To implement these behaviors, and consider about other keyboard
behaviors which is special to menus, I believe it justifies
to create another class for the menu popups rather than using
ListPopupWindow directly.
Bug: 19642104
Change-Id: I5e405c0491c67fdef9764898701119979ec13a9f
In situations where the hint text does not match the direction of
the TextView's primary selection, when you copy text, and long press
in that EditText to paste, the cursor would use the direction of the
hint text to be placed, whereas the handle and floating tool bar
used the TextView's direction to be placed so they wouldn't match.
This CL updates the handle view and floating tool bars to use the
hint text direction when appropriate.
Bug: 21480429
Change-Id: I8090a5b2738c035522c307535ffa165ca024e811
TextView is now much smarter about the text it reports, limiting it
to what is visible (plus a bit more). Also add a facility for it to
report where the lines of text are, both as offsets in the text string
and their baselines on screen.
Part of fixing issue #22328792: Fix scalability issues in AssistStructure
Change-Id: Idddb8c3a3331355f381e2d4af06d520fe7c7ce8e
