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
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
...to an explicit toggle to enable in Settings
Add a new permission flag, saying the permission can be automatically
granted to pre-api-23 apps. Apply this to SYSTEM_ALERT_WINDOW.
Change-Id: I24a0ceabe7e9f5e458a864d30eda2696ad14a699
If extracted mode is to be started and we already had a
selection made do not start the action mode but only the
selection. Non-extracted mode keeps the current behavior.
Bug: 22100966
Change-Id: Iad9a95c28474a68dc4fbc7032cbab1dc6e234d45
This happened as selection handles are shown even when
selection action mode is not active.
Bug: 22188927
Change-Id: Ifd88b91d98cc6f9b0c578e782144b6eee1bdeec9
The beginning divider should draw before the first child that is not
set to GONE. Incidentally, there needs to be a check for such a child,
which involves checking the visibility of all the children with lower
indices. This CL takes into account the scenarios where children with
lower indices could be null, in which case we'll treat them as if they
were GONE.
Bug: 22199594
Change-Id: Iefc73ef87beec219898c967b9a3ccebd1e3b5b4c
Provides consistency with setImageDrawable(). Also updates docs and
annotations for setImageZzz() methods that can take null.
Bug: 21664964
Change-Id: Ia9b7f8ee9edb23eeea457520bea4dd261decc794
This CL adds a step to resolve CompoundButton's foreground drawable when
layout direction has been changed. Prior this CL, only background drawable
of the button resolves its layout direciton in respond to system wide
layout direction change. This CL makes the foreground and background
drawables consistent in layout direciton.
Bug: 16376848
Change-Id: I9a4eb1e010e6ab61ef8684005508bd36486ec1f3
Also refactored the code so that PROCESS_TEXT-related code is shared
by menu item actions and accessibility actions.
Bug: 21890235
Change-Id: Ie932fa9bb5cd3d8bd29f8c82695f3c7490693cbd
Some languages do break words across lines and words can break between
lines with hyphenation. If a word has only one character on the current
line with the rest of the characters on the next line, the user would
be unable to move the cursor to the end of the word.
Rather than judging if a user is far enough into a word by using the
full word length, this CL amends the logic to only use the characters
that are on the current line of the word, if the user is far enough into
these characters the handle jumps to the next line to the end of the
word position.
Bug: 21400624
Change-Id: I8b96eb83bea08d9794d1e9db74066bcc3e168ac0
Also turns off ViewPager debug, enabled the scroll indicator on the
DatePicker's year list, and updates the year label's TextView ID to
something more reasonable. Some code cleanup inside ListView.
Bug: 20110431
Change-Id: If1dba955094524d69cc297d7a567a182cef7f11d
If you select some text normally while in accessibility mode, it
should be cleared and handles should not show if you initiate text
selection using the accessibility context menu.
Bug: 22071639
Change-Id: I32b966e771ba5715a0ab370e6aa602398e5ec534
