Also ignore the requestedPermissionFlags of yet to be installed
packages when trying to determine if a permission is new.
Bug: 22229417
Change-Id: I59d579cdc42d64bcfdefdb06e1576959355bb7a4
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
- 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
AbsListView has special handling of header and footer views that avoids
full attachment; however, we still need to fully detach and reattach
non-header/footer views that cannot be recycled.
Bug: 22239425
Bug: 22238597
Bug: 22214485
Change-Id: Iae5f954fc76522c0a52d0c25e19985ae0196efa2
Ensures behavior is consistent between accessibility focus retention and
keyboard focus retention. Attempts to retain focus when possible.
Bug: 22207825
Change-Id: I62360892f52d456e2128f93a2dbf18f2bc934ef3
