Do not compute outside given range in TextLine
This is second attempt of I646851973b3816bf9ba32dfe26748c0345a5a081
which breaks various layout test on application.
The empty string must be also handled by the TextLine since it
retrieves the default line height from the empty string.
Bug: 140632678
Test: StaticLayoutTest
Test: Manually done
Change-Id: I7089ed9b711dddd7de2b27c9c2fa0fb4cb53a735
The CL fixes a crash in Layout.primaryIsTrailingPreviousAllLineOffsets.
The crash was happening when the method was called for a line beginning
with an empty bidi run. This could happen, for example, for empty text -
I was unable to find any other case. The CL improves the existing test
for the method with this case, which was previously crashing.
The CL also fixes a potential crash in getLineHorizontals. However, this
bug could never happen as in the current code path clamped is always
false (and kept as parameter for parity with getHorizontal).
Bug: 135444178
Bug: 78464361
Test: atest FrameworksCoreTests:android.text.LayoutTest\#testPrimaryIsTrailingPrevious
Change-Id: I47157abe1d74675884734e3810628a566e40c1b4
(cherry picked from commit 7ad499d007)
Also don't show smart actions for selections in text with unsupported
characters.
Bug: 116321860
Test: runtest -x cts/tests/tests/text/src/android/text/util/cts/LinkifyTest.java
Change-Id: Ib2ee544b5783234fba8ee2f93adf0b36b039520f
Merged-In: Ib2ee544b5783234fba8ee2f93adf0b36b039520f
Also don't show smart actions for selections in text with unsupported
characters.
Bug: 116321860
Test: runtest -x cts/tests/tests/text/src/android/text/util/cts/LinkifyTest.java
Change-Id: Id271cab8aef6b9b13ef17f1a8654c7616f75cf13
The crash was introduced by Ib66ef392c19c937718e7101f6d48fac3abe51ad0
The root cause of the crashing is requesting out-of-line access for the
horizontal width. This invalid access is silently ignored by
TextLine#measure() method but new implementation end up with out of
bounds access.
To makes behavior as old implementation, calling getHorizontal instead
of accessing measured result array.
Bug: 78464361, 111580019
Test: Manually done
Change-Id: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
(cherry picked from commit 960647d582)
Merged-In: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
The crash was introduced by Ib66ef392c19c937718e7101f6d48fac3abe51ad0
The root cause of the crashing is requesting out-of-line access for the
horizontal width. This invalid access is silently ignored by
TextLine#measure() method but new implementation end up with out of
bounds access.
To makes behavior as old implementation, calling getHorizontal instead
of accessing measured result array.
Bug: 78464361, 111580019
Test: Manually done
Change-Id: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
(cherry picked from commit 960647d582)
Merged-In: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
Layout#getOffsetForHorizontal was running in O(n^2) time, where n is the
length of the current line. The method is used when a touch event
happens on a text line, to compute the cursor offset (and the character)
where it happened. Although this is not an issue in common usecases,
where the number of characters on a line is relatively small, this can
be very inefficient as a consequence of Unicode containing 0-width
(invisible) characters. Specifically, there are characters defining the
text direction (LTR or RTL), which cause our algorithm to touch the
worst case quadratic runtime. For example, a person is able to send a
message containing a few visible characters, and also a lot of these
direction changing invisible ones. When the receiver touches the message
(causing the Layout#getOffsetForHorizontal method to be called), the
receiver's application would become not responsive.
This CL optimizes the method to run in O(n) worst case. This is achieved
by computing the measurements of all line prefixes at first, which can
be done in a single pass. Then, all the prefix measurement queries will
be answered in O(1), rather than O(n) as it was happening before.
Bug: 79215201
Test: manual testing
Change-Id: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Merged-In: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Layout#getOffsetForHorizontal was running in O(n^2) time, where n is the
length of the current line. The method is used when a touch event
happens on a text line, to compute the cursor offset (and the character)
where it happened. Although this is not an issue in common usecases,
where the number of characters on a line is relatively small, this can
be very inefficient as a consequence of Unicode containing 0-width
(invisible) characters. Specifically, there are characters defining the
text direction (LTR or RTL), which cause our algorithm to touch the
worst case quadratic runtime. For example, a person is able to send a
message containing a few visible characters, and also a lot of these
direction changing invisible ones. When the receiver touches the message
(causing the Layout#getOffsetForHorizontal method to be called), the
receiver's application would become not responsive.
This CL optimizes the method to run in O(n) worst case. This is achieved
by computing the measurements of all line prefixes at first, which can
be done in a single pass. Then, all the prefix measurement queries will
be answered in O(1), rather than O(n) as it was happening before.
Bug: 79215201
Test: manual testing
Change-Id: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Merged-In: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Also, in TextLine, fix underline color and thickness to come from the
underline info rather than the TextPaint object.
Bug: 32907446
Bug: 62353930
Test: Manual
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Test: cts-tradefed run cts-dev --module CtsWidgetTestCases
Change-Id: I259e9cf635a7056ccd367baa77c03100c69e3b98
Previously, we had singled out UnderlineSpan for special treatment
for proper kerning at span boundaries. That had the limitation that
any other span that used underlining, or even subclasses of
UnderlineSpan were not getting the fix.
With this CL, we actually look at all the effects of applying a
span's updateDrawState() and if the changes were only in underlining,
we merge the pieces and call handleText() on the merged chunk of
text.
Change-Id: I829162c758192b80594f164d1105699224b627ba
Bug: 32907446
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Test: cts-tradefed run cts-dev --module CtsWidgetTestCases
Test: manual
Previously, text that was partially annotated with an UnderlineSpan
could have a different width than text without it, since underlined
text was separated into a separate piece of text and was measured
separately, causing kerning at the span boundaries to disappear.
Change-Id: I118de8524c500fb6a4b05b1bf65fe93dc67f204c
Bug: 32907446
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Test: manual
The changes in I666da5eeb39f780c341597f347bfcba21eb34295 introduced
the concept of lines that need to be always redrawn, but it broke
tests for DynamicLayout#updateBlocks() that didn't need to set up the
actual lines.
Now, during the test setup, we insert empty lines to match the number
of lines needed.
Test: adb shell am instrument -w -e class android.text.DynamicLayoutBlocksTest com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -w -e class android.text.DynamicLayoutTest#testGetBlocksAlwaysNeedToBeRedrawn_thai com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -w -e class android.text.DynamicLayoutTest#testGetBlocksAlwaysNeedToBeRedrawn_en com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Change-Id: I4bfc82db4beef1b740433a25a3ae29201f54d9d3
Fixes: 38029583
Text classification is now being done entirely in the app's proccess.
See android.view.textclassifier.TextClassificationManager
Reverts Ic428d00f291e268211866b3fc6b7acbc3eb04e1e
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Fixes: 36852122
Change-Id: Iffff3ab6e7d3b761576eb6bdcd5032db34b7a1b2
This switches TextUtils.concat() to use SpannableStringBuilder
if there are any spans in the input strings. As a result, we can
avoid crashes when concatenating two CharSequences can result in
paragraph spans that now don't happen to be at paragraph boundaries.
Also document the exact behavior of the method for edge cases based
on the previous implementation.
Change-Id: I9caffbe95ed729b9c10d63a9e7d22b1e8c7185a3
Fixes: 28271770
Test: CTS tests added and old CTS tests continue to pass.
Test: cts-tradefed run cts-dev --module CtsTextTestCases --test android.text.cts.TextUtilsTest
For AssistStructure, and AutofillValue, create a copy of the text in
setText and forText methods if it is a Spanned.
Fixes: 36838999
Test: cts-tradefed run cts -m CtsAutoFillServiceTestCases
Test: cts-tradefed run cts -m CtsAssistTestCases
Test: cts-tradefed run cts --test android.widget.cts.TextViewTest -m \
CtsWidgetTestCases
Change-Id: I52e780fa9baa17c375d3945dc714171f41fd7db5
Reverts I772961bd20bff4817a060f14a843abeceb55ac92
Until we bring back TextClassifier.getLinks
See I275a9d055ef0ab68f3ca339c37ee939257c4bd54
Test: none
Bug: 22362008
Bug: 37565246
Change-Id: I2948f22cf4c3462491f47376af48624697703969
Services recycle nodes when gathering possible actions
for users to take. It's very confusing for them if they
can't recycle the node without breaking their ability
to activate a clickable span inside it.
Making ClickableSpans used for accessibility independent
of their parent nodes.
Also adjusting the value used for invalid window ids to
come from AccessibilityWindowInfo. I must have missed this
in an earlier cleanup. I needed the value for the spans,
so I figured I might as well use the correct one.
Bug: 37004527
Test: Now recycling the node in the a11y cts test.
Change-Id: I6de4e98a182dd43c4fcd0430a3c082fcc8e458c7
We now use ICU's new functionality for casing edits to preserve
the spans while applying AllCapsTransformationMethod.
Test: Manual
Test: CTS tests added and pass
Bug: 7198872
Bug: 19047649
Bug: 19713814
Bug: 34853618
Bug: https://code.google.com/p/android/issues/detail?id=67509
Change-Id: I0df388e79894961efb272d497f1dcc0570a6c085
By I9ccafe7a53935960566243e2856e166878ca59ae, FontManager was gone.
So FontConfig is no longer need to be parcelable.
We can drop Parcel interface from FontVariationAxis.
Bug: N/A
Test: N/A
Change-Id: I33e92abf1e1063af312f0b7d9d6b8bd938d09c0e
FindAddress method only ever worked on US addresses and being a part
of WebView API, it required the users that did not use WebView otherwise
to pay a heavy penalty. Further, it was also used by Linkify.
The new way to find addresses is using TextClassifier.
Bug: 22362008
Test: WebView.findAddress.
Change-Id: I772961bd20bff4817a060f14a843abeceb55ac92
Update SpannableStringBuilder, SpannedString and SpannableString classes
so that they don’t enforce paragraph constraint for copy constructors.
If a paragraph constraint is not satisfied for a span, that span is not
copied. Before this change it would throw an exception.
Test: New tests added for SpannableStringBuilder and SpannableString
cts-tradefed run cts -m CtsTextTestCases
Bug: 36511794
Change-Id: I62abf08a8d4fe7e342ed97b8e8c3a577a9397e39
