This works around a bug in standalone (e.g. non-Zygote)
runtimes when a device is attached to a host that is running
DDM.
There is a race condition:
When the runtime receives a HELLO from DDM it calls
TextUtils.isEmpty().
Calling any TextUtils methods statically initializes
Layout. Layout has dependencies on other classes, which in
turn have dependencies on native methods that are not always
registered when the call takes place. Registration and DDM
handling are done in separate threads.
This is not a fix, merely a workaround until the race can
be resolved.
Bug: 18081539
Change-Id: If1bd3de6597bc93da381c8f86dacf40156449561
All supported locales use only U+2025 and U+2026 to represent
ellipses, and it will unlikely change in future. Given translated
resources are inconsistent and often use three dots it is safer
to use constants instead of resources.
(cherry-pick of ed0daa93e48d38e54a7ad1c99c461510a4c07599.)
Bug: 18542179
Change-Id: I51a6cb903f62f739fbadd6b78e5765c0028d641a
TextLine was not fully cleared before recycling it which leads to
activity leaks if the activity happens: to register a text watcher.
bug:19045507
Change-Id: Ife0f7ce29865bd30ca2dfe8795023f51f275d659
This reverts commit 9dfe86d410.
That change moved the lenience from POSSIBLE to VALID, which eliminated
false positive links, especially 4 digit phone numbers, but caused
significant false negatives, leading to CTS test failures
(android.text.util.cts.LinkifyTest#testAddLinks7 in particular).
The true fix requires new functionality to validate phone numbers in
a mobile context. In the meantime, the best solution is to revert.
Bug: 18708556
The linkify logic used POSSIBLE as its leniency setting, which resulted
in false positives such as 4-digit years being interpreted as phone
numbers. Changing to VALID as per recommendation of libphonenumber
people, which fixes this problem.
Bug: 18489494
Change-Id: I77d330285de46de2fdda22daed41392106ec6ddd
In the Truncate.MIDDLE case, when the line is less than half the layout
width, the computeEllipsis logic could go past the left edge of the
string. This patch fixes the off-by-one and avoids the resulting index
out of bounds crash, and also changes the behavior so that when
ellipsizing at the middle, the string to the end of the paragraph is
taken into account.
Bug: 18508627
Change-Id: I24be09c23a5aa158791a9717419307613b8a22e8
The 24 hour setting was not respected correctly. Also
fixed a bug where the next alarm would not display itself
in the QS panel.
Bug: 16239208
Change-Id: I89734f783912dead5831db49db53fba04dbf54ee
The "moreChars" test in StaticLayout's generate method would evaluate to
false when the last character in a word caused the break. This in turn
suppressed the ellipsis in this case. The proposed fix is always to set
moreChars true in the code path where the line is broken because more
text wouldn't fit.
Bug: 17738112
Change-Id: Ifa1a69841ca952da4d1937dc8326778179b026b3
With a hardware keyboard, using up arrow within the top line should
move to the beginning of the buffer, to better match desktop text
editing expectations, and similarly for down arrow on the last line.
This patch implements that behavior.
Bug: 17385784
Change-Id: Ia23c23c9cc2462558bca9aaffec7d83e284d55e8
We weren't getting correct results from Layout.isRtlCharAt, because it
was only testing half of the correct predicate for whether the argument
was inside the run. This patch restores the correct predicate.
Bug: 17381011
Change-Id: Ib0a77cc182f4ca4bfe824e85b7aff7268f465d73
The test fixes for bug 17262063 showed up a real issue for
non-English locales with the Time.format() method:
If the Android string resources that contain the pattern use
non-ASCII characters then a '?' would be output instead of
those characters.
For example, in France the pattern for '%c' includes a 'à'
(a with a grave accent) and Japan includes 日.
The problem was due to converting the pattern to bytes using
the US_ASCII character set, which turns non-ASCII characters
into '?'. The code has been changed to use char throughout
and avoid bytes.
Internal documentation has been improved.
Some calls to modifyAndAppend() have been replaced with a
direct call to outputBuilder.append() because the
modify step is guaranteed to a no-op for the literals given.
The formatter has been changed to use Locale.US because it
is only used for outputting numbers. It has been renamed
to make this more obvious and the locale field has been
removed.
Bug: 17262063
(cherry picked from commit 788cb18f65)
Change-Id: I96ee158fbeb01827f0bbf022631625416f872fdb
We used the full width of a line, including trailing spaces, to compute
ellipsis, sometimes causing spurious ellipsization when the space pushed
it past the layout width. This patch uses only the width up to the last
graphing character.
Fix for bug 17186801 "First line of title text is getting truncated even
if there's space on second line"
Change-Id: I49d07c18c8dd1d3b279f591224d23e10645dc8c0
This addresses b/16486549.
This change updates public documentation to specify the behavior of
LeadingMarginSpan2s. This change specifies what happens when a
LeadingMarginSpan2 is combined with other LeadingMarginSpans. This
behavior was not previously documented.
LeadingMarginSpan2s specify the number of lines used for the leading
margin. When laying out and rendering, for all LeadingMarginSpans, the
first line margin is applied for the number of lines specified by the
LeadingMarginSpan2.
Previously, this behavior was slightly buggy -- the LeadingMarginSpan2
affected all LeadingMarginSpans when laying out text, but not when
rendering.
This change is designed to cause the least amount of breakage in
existing code while achieving consistency with the way
LeadingMarginSpan2 is handled in layout and drawing.
For the most common use of LeadingMarginSpan2 -- getting a multi-line
first margin in the first paragraph of text in a layout -- this should
cause no change in behavior. For any other uses, the old (buggy)
implementation most likely did not exhibit correct behavior to begin
with, so developers were most likely not relying on that functionality.
Change-Id: I6f69df09c0130e703458e65bf3eaac4a905df56e
.. and use Locale.getScript() instead of ICU.getScript.
bug: 15876704
(cherry picked from commit 08b3516984)
Change-Id: Ifac179e0577d66062f32c95372b631bf574dfdf9
This fixes b/16510772.
When measuring paragraphs, leading margins should be taken into account.
When computing line width, the margin should be added to the absolute
value of the extent (there were missing parenthesis). Both of these
caused views with leading margins to be rendered incorrectly.
Change-Id: I5029b2790a249192a858eb226d7b793d0622a70d
The reason for separate classes for each type, instead of a more flat
structure is to enable easy discovery of the available arguments that
can be set. For L we'll have about 12 types with 30 arguments and
almost all of the arguments are type specific. In future releases
we'll introduce more arguments. With editors that have code completion
one can construct a span without having to consult the documentation.
For now it only contains Text and Cardinal types.
Change-Id: I94531e600133d9f4f59a4170cceef1ee7a360ca7
(cherry picked from commit 90b095aabd8a5c43723821dda37354fd2beb38fb)
The TtsSpan can be used to provide addtional data for TTS engines.
For now it only includes the types text and cardinals, but more will follow.
Change-Id: I31392dd413c0902ba4ce702fa3307253c90c618f
Clusters were broken incorrectly when in narrow views (when the width of
the cluster was greater than the width of a view). Also, out() calls
were modifying fm, so clusters that were too wide were not positioned
correctly.
Change-Id: I521f8dc6338f5f1de6858af3f0c0bd320aa46bc0
Incorporate patch from Logitech (donated under AOSP license) to the
framework to add mouse-based text selection to ArrowKeyMovementMethod.
Bug: 14652753
Change-Id: Iab264bb954b72ccedfada763eba8f13ef37a4578
The dirFlags and bidiFlags enums are distinct, and have different
meanings. The former is a determined direction for a run of text, while
the latter is a request for the bidi algorithm. They have been used
interchangeably, and this has caused some problems, notably running the
bidi algorithm needlessly when the direction for a run is already
determined.
This patch cleans up the confusion, by always naming each occurrence
explicitly "boolean isRtl" or "int bidiFlags" (the previous code often
just used "int flags", which added to the confusion), and converts
between the meanings when a function takes an isRtl argument but passes
it to another function expecting bidiFlags.
Fixes b/15089607 Clean up bidi flag mess
Change-Id: I410b6604376e853dd12c255e7f5a9d2b9a310dd9
SpannableStringBuilder should throw an exception when the
parameters to #insert and related methods are in the wrong
order.
We'll have to reopen b/9570771 and deal with it separately.
Bug: 14965397
Change-Id: I01847e0010d23f98ad3def8ba030d36570528900
This fixes a CTS test for Wearable. We cannot check for FEATURE_WEBVIEW, because
there's no way to get a PackageManager from within these static methods.
Bug: 15131296
Change-Id: I7bf7564b6209f330a413ed54a94be1e07fedb30d
