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
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
