Enable API user to create their own URLSpan for Linkify operations.
Test: atest android.text.util.cts.LinkifyTest
Test: atest android.text.util.LinkifyTest
Bug: 28536972
Bug: 32613009
Bug: 29150779
Change-Id: I9a2f995656bd1510502e5517ac737b47ebd33130
Enable API user to create their own URLSpan for Linkify operations.
Test: atest android.text.util.cts.LinkifyTest
Test: atest android.text.util.LinkifyTest
Bug: 28536972
Bug: 32613009
Bug: 29150779
Change-Id: Ia4495dc7e656044b91a79804d3b50a30cae98225
Another CL in this topic changes the behavior of String.split() and
Pattern.split() to omit a "" generated by a leading zero-width match.
TextUtils.split() is implemented on top of these methods and therefore
adopts the behavior change by default.
The behavior change only affects apps targeting API versions > 28.
Test: cts-tradefed run singleCommand cts-dev -m CtsTextTestCases \
-t android.text.cts.TextUtilsTest
Test: cts-tradefed run singleCommand cts-dev -m CtsLibcoreTestCases
Bug: 109659282
Change-Id: I8abe251353f8eacf1429ac9a8e272d50a0944c29
doclava was accidentally suppressing all these broken links
in @see tags. This CL fixes issues so we can start enfocing
checks for broken @see links.
Test: make docs
Change-Id: If7830ece85f8d1f27c991eae282230814726e115
Exempt-From-Owner-Approval: Fixing @see javadoc link issues that are currently completely broken
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
When a sequence of characters belonging to a text is ellipsized, we
usually replace the first characters with ... and then all the others
with a 0 width character, knowing that they will be drawn, but will be
invisible. However, these positions could have had ReplacementSpans
attached to them, such as EmojiTypefaceSpan when the EmojiCompat library
is used. When this happened, all the ellipsized out characters were
invisible, apart from emojis, which were still drawn as usual (as they
were replacing sequences of 0 width characters).
This CL fixes this behaviour, by skipping those ReplacementSpans that
were completely included in ellipsis. Please check the bug for a more
detailed explanation.
Bug: 69802699
Test: manual testing
Test: atest FrameworksCoreTests:android.text.TextLineTest
Change-Id: If9758537948abaa0226fe6b551a703110c5457b9
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
The underline and stroke should be top of the text.
This regression happens on O-MR1 and the root cause is still unknown,
but the drawning underline/stroke should do before drawing text.
Bug: 79906191
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Idc2f99b9c0fa125af331e496da8daa326d14bfac
It is common for TextView subclasses to override the #setText method,
and there is nothing preventing the new implementations from leaving
mText and mTransformed unchanged. On the other hand, TextView assumes
mText and mTransformed will be non null at all times after the first
overridden implementations, these can remain null, causing null pointer
exceptions later.
Bug: 74411872
Test: atest FrameworksCoreTests:android.widget.TextViewTest
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: Ifaddb46d156c495a371789c6f32cfd67ffaaaef2
Bug: 77998709
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: Ibb95a736248643949a7b521368374084f9f133ca
This CL removes the Emoji 5.0 info from Emoji.java since they are
supported by ICU. It adds emoji added in Emoji 11.
Test: atest android.text.EmojiTest
Test: Verified that ICU handles Emoji 5.0 emoji
Test: Verified hardware keyboard backspace with hair color emoji
Test: Visually verified cursor moves with hardware keyboard
Bug: 77148691
Change-Id: I40b290fcea201cf5e35ad4c461f8d8056b8c3739
(cherry picked from commit 213388d254)
This CL removes the Emoji 5.0 info from Emoji.java since they are
supported by ICU. It adds emoji added in Emoji 11.
Test: atest android.text.EmojiTest
Test: Verified that ICU handles Emoji 5.0 emoji
Test: Verified hardware keyboard backspace with hair color emoji
Test: Visually verified cursor moves with hardware keyboard
Bug: 77148691
Change-Id: I40b290fcea201cf5e35ad4c461f8d8056b8c3739
Smart Linkify changed their interface to use TextClassifier and
previously @hide addLinksAsync functions. Currently the core tests fail
and the functions are not being used.
Test: N/A
Bug: 77641809
Change-Id: Id1f595bf3e0c4d8c77da4d52e6699a8bb3117659
Consider an app targeting the final API 28, but running on an older
build where "P" is still API 10000. Those apps need to be treated as
legacy apps.
In general, the logical pattern that should be used when enforcing
target SDK behaviors is below.
For applying behavior to legacy apps:
// BROKEN
if (targetSdkVersion <= Build.VERSION_CODES.N_MR1) {
// CORRECT
if (targetSdkVersion < Build.VERSION_CODES.O) {
For applying behavior to new apps:
// BROKEN
if (targetSdkVersion > Build.VERSION_CODES.N_MR1) {
// CORRECT
if (targetSdkVersion >= Build.VERSION_CODES.O) {
Bug: 77865751
Test: builds, boots
Change-Id: Ia83bd446a940751d51a6542c7a5b9cca174c5296
Add flags to let callers specify if they want IEC (power-of-two) or
SI (power-of-ten) units when formatting bytes.
Continue using SI units by default, since certain folks seem to have
strong opinions about that.
Bug: 76159924
Test: atest android.text.format.FormatterTest
Exempt-From-Owner-Approval: previous PS approved
Change-Id: I0074bb2578c2230e938b3f39c2564b1083feb825
The root of this bug was in the fact that Selection.removeSelection
removes two spans, the start index and end index of the selection.
Each span removal triggers Editor#onSpanRemoved, which in turn tries
to set a selection. This meant that if we started with selection
(100, 120), then removeSpan(start) was called, so we had (-1, 120),
then the onSpanRemoved code tried to set a selection so set it to
(120, 120), then removeSpan(end) was called, ending up in (120, -1).
There are two stages to this fix
1. A lot of our code assumes that when either start or end selection
are larger than -1, both are valid. Therefore when we have one of them
out of sync, we crash. Fixed this assumption in all the places I found
2. We didn't have a mechanism to use FLAG_INTERMEDIATE when removing
spans, only when adding them, so this CL adds a remove with flags. This
allows us to not trigger onSpanRemoved when only one of the selection
indexes is removed.
Because this is an added method to an interface, the default just
calls the existing method. The new method is implemented in
SpannableStringInternal and SpannableStringBuilder to read
FLAG_INTERMEDIATE and avoid sending a spans changed event.
Selection.removeSelection then uses FLAG_INTERMEDIATE when removing
the first of the two selection spans.
Note that 2. would be enough to fix the current bug, but we want to
avoid other implementations of Spannable from crashing in the wild.
In general, it seems like a good idea to verify both selection indexes
are valid whenever they are used.
Bug: 72101848
Test: atest FrameworksCoreTests:SpannableStringBuilderTest
Test: atest FrameworksCoreTests:SpannableStringTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsWidgetTestCases:EditTextTest
Test: atest android.text.cts.SelectionTest (note new test as well)
Test: atest android.view.inputmethod.cts.BaseInputConnectionTest
Test: atest android.text.DynamicLayoutTest
Change-Id: I0d647fad152d0bef0f2115a46c3d17ebd8642281
This is from advice from API review.
- make getText() hidden
- make getWidth()/getBounds() public.
Bug: 76448719
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ic22a266a932cda60de6d8b37b8bbf5704291b953
1. Wraps TC queries in Request objects
2. Adds create/destroyTextClassificationSession system APIs
3. Adds the session Ids to system API calls
4. Change setSignature() to setId() on result objects
5. Plumbing to make the API updates work as things currently work
6. Hide Linkify.addLinksAsync APIs
Bug: 74461129
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextSelectionTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextLinksTest
Change-Id: I933ada8b37ef9893331a265e3b4fc08e043f1029
