This is a preparation to deprecate the following two methods.
* InputMethodManager#getInstance()
* InputMethodManager#peekInstance()
Since we soon need to stop relying on the current per-process
InputMethodManager singleton model to fully support multi-display,
those two methods really need to be deprecated.
With this CL, framework code no longer depends on
InputMethodManager#peekInstance(), which is also marked as deprecated
in this CL.
InputMethodManager#getInstance() is a bit tricky because it also works
as a constructor of such a per-process singleton instance. Remaining
two call-sites of this method will be migrated in a subsequent CL.
This is a mechanical refactoring, which in theory should have no
observable logical behavior difference.
There could be a small performance regression, but it is basically not
avoidable to correctly support multi-display scenarios.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest CtsWidgetTestCases:android.widget.cts.EditTextTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.textservices
Change-Id: I5db31491f3d47d3ad4a621e956995135c72e007b
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
These APIs are necessary to implement hyphenation by third party developers.
Bug: 112327179
Test: atest android.graphics.cts.PaintTest#testSetGetHyphenEdit
Change-Id: I692a56d3d1b15100503eb6d8e0f59d6c5c8af81b
To be able to use font file in their apps, provides blob and path to the
font file and locale list as well.
Bug: 26116537
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
CtsGraphicsTestCases:android.graphics.font
Change-Id: I1ae1302c6906b808012e1e91b1e4ab393c887cb6
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
For packages:
android.text.util
android.text.style
android.text.method
android.text.format
android.text
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I5be178ad05f2ff98bcf31e24cd4eb33961887c38
Merged-In: I9afbd4ca8826c37cb70db43252e39b9a674e5ae0
Previously we have updated the code not to check mHorizontals if offset
is invalid (I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8) However we should
also check the final index to make sure no invalid index is accessed.
Test: None
Bug: 111580019
Change-Id: I5c32820cde5f91bfe8688e9394b8ba3254cbd731
For packages:
android.text.util
android.text.style
android.text.method
android.text.format
android.text
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I9afbd4ca8826c37cb70db43252e39b9a674e5ae0
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: 111580019
Test: Manually done
Change-Id: I5c5778718f6b397adbb1e4f2cf95e9f635f6e5c8
Test: none
Circles are historically actually easier to draw than Paths for HW
acceleration, though they're equivalent in Skia.
Change-Id: I1a7e2ca6439b6a09fdac784237065668db8cadc6
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
