onPreDraw starts an action mode in extract mode only which
does not consider the type of motion event and since extracted
mode never gets the focus event it never hides so it does not
need to show again.
Stop starting an action mode onPreDraw in extracted mode and
let the onTouchEvent handle starting the mode.
Also re-enabled dragging and dropping for ExtractedMode (most
of the issues were caused by starting the action mode
onPreDraw).
Bug: 25102276
Change-Id: I90d8e9f42f395b6b529e4d023ba6939e0dfb147f
Views are not synchronized with adapter state until a layout pass
occurs, which may cause an OOBE if a list item is removed and an
accessibility node is obtained before the next layout pass.
This CL caches the item's enabled state on the bound view's layout
params, which allows us to avoid relying on the adapter to populate
accessibility nodes. It also aborts actions if the target position
is no longer valid.
Updates the documentation on AdapterView to reflect that the result
of getPositionForView() may not be synchronized with the adapter.
Bug: 23943664
Change-Id: I90ca946bead1d87a179eab1c2f482a54bcce9c38
When long pressing on an empty Text field with the system language set
to RTL, the "paste" popup was not showing up.
The Floating Toolbar requires a content rect to determine where the
text is and place itself close to it. In the case of an empty field,
we create a "fake" content rect by taking the placement of the cursor
+1 pixel to the right. In RTL languages, this +1 causes the content
rect to be considered off the bounds of the view, as the cursor is
aligned to the right, and hence the Floating Toolbar is hidden.
After making the rect a 0 width rect, we ran into the issue that
it was considered out of bounds due to the calculation ignoring rects
that simply touch the edge of the view's bounds.
BUG: 22540083
Change-Id: I29c79b701f586970b2611178233eff082b802ec1
We were always setting the background of the decor view when the
"above anchor" state changed, rather than the background view.
Bug: 22970244
Change-Id: I3cd7202767ee47cb415736bb3c07369801abccd8
An optimization in ImageView nulled out the internal bitmap of a cached
internal BitmapDrawable object created to wrap a bitmap set on the ImageView.
However, apps can get ahold of that cached object via Drawable.getBitmap(),
resulting in having the state of that object they may be using changing out
from under them.
The change is to null out the cached object when getDrawable() is called, to avoid
leaking internal state that we may change.
That way, the app can continue to use that object if they want to, but we are no longer
relying on it internally, and will create a new one when needed.
Issue #22930646 [1P Regression from L] ImageView is blanked out in Activity in Google Express
Change-Id: Ic86cb93be4897b6ba247c1fabcda507e4ba01300
Currently update() bails out early if it is called
too soon after mStartTime has been set. In this case
mCurrentPosition remains holding an obsolete value
from a previous animation. This causes some strange
behavior (see the referenced bug).
This patch makes sure that mCurrentPosition is
updated every time that mStart is updated.
Bug: 22950559
Change-Id: I07b92f30ebe29856f4e04dc19a4820123713fd7e
"Include non-zero dimension views in excess space calculation" and
"Always distribute excess space in LinearLayout measurement" changed
LinearLayout behavior significantly in a way that wasn't covered by
CTS tests.
This reverts commits da2f304409 and
4fabc02158.
Bug: 22862047
Change-Id: I8d37a525ccf295445d3239b80e5cacb10bf3c947
In particular, some clients (*ahem* SystemUI) have been
known to inflate RemoteViews with unusual derived contexts
that may not have valid application contexts. DateTimeView
can now resist this.
Bug: 22852700
Change-Id: I5e91ae0e66859f5f5efd7b19c0ae6dfbc26bcc54
Icon needs the RemoteViews' internal context to reflect not
just the Resources of the originating application, but its
package name as well.
Bug: 22840771
Bug: 22852700
Change-Id: I1164cd38d99283982b00daadcf927c7cf63539b3
The problem is that, for 12-hour locales, we cut the "a"
part of the time format out to show it in a separate
TextView so it can be animated independently of the actual
time. Unfortunately, while TTS is smart enough to pronounce
"1:15 AM" as /wʌn fɪftin eɪ ɛm/, "AM" on its own looks like
the English word "am" and is pronounced /æm/.
To fix this, a TextClock must be able to accept separate
formats for its content description than its presentation.
With this capability we can place the complete 12-hour time
format (including am/pm) in one of the views and suppress
the other one, so that the utterance creates an identical
experience to visual inspection: "1:15 AM" for all users.
Bug: 21718000
Change-Id: Ic9920d71ae4d4ad41ba86d7bd96f9a19b07e2108
Previously, excess space was added to existing measured dimensions.
This consistently resulted in incorrect allocation of excess space,
since the delta already included the height of any measured children
rather than just the excess space itself.
This CL ensures that excess space is always distributed according to the
layout weights.
Bug: 22810327
Change-Id: I482a553c469169769cc40ab3d88b4a44023f3eb5
RemoteViews now allows Icons as TextView compound
drawables in RemoteViews, but not yet as public API.
Bug: 22600607
Change-Id: I986a0ce3bede09746f0b121884184679f39a79f5
When selecting text and expanding the selection, the handles snap
to the end (or start) of words. The handles don't snap until the
user has moved halfway through the word.
In horizontally scrolling text views, where some of the text is
cut off, the user cannot be halfway through the word, this causes
the selection to get stuck unless the user scrolls the view and then
continues selecting.
This CL does two things:
1) Checks if the user is close to the edge of the view when the
view can scroll horizontally, and places the cursor at next offset
if available.
2) Moves the code to check if handles are crossing into own method
this should be done each time the cursor is placed and avoids the
need to duplicate the check throughout updatePosition code.
Bug: 22657879
Change-Id: Ic14cb0994cd202a897bf6532f3832bb93ed49bfb
Some views are backed by adapter and if the adapter changed
but views are not updated we were not reporting the views.
This is not correct as the accessibility layer should always
access whatever is on the screen regardless if we know it
will change in the next layout pass.
bug:20920903
Change-Id: I5851c886848e7b8e59b76419c22124790d7e6f05
Replace text was handled by the original EditText; thus, we
couldn't correctly decide popup window position.
Also, changing selection range replaces entire text of the
extracted EditText. As a result, text cannot be replaced
with the selected item when there is a selection.
This change is a workaround for this issue. This quits
offering "Replace" for selection in extract mode.
Bug: 22038802
Change-Id: I052b027cfd10eeb289f77f4c6b228acf58fea636
The days of the month were not being localized, resulting in
English numbers for non-English languages. Now we format the numbers
with the current locale.
Issue #22540629 [MRA14D][Arab][Token] numbers displayed in english
Change-Id: I2b17d55ba2d0aa47b5a28c8846c6cf9723ababb1
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
