Instead of iterate all ellipsized characters, only iterate the necessary
ranges for copying.
Bug: 188913943
Test: atest CtsTextTestCases CtsGraphicsTestCases CtsWidgetTestCases
Change-Id: I3d03b1e3897e427c23fbe51315f412c57a4ce9e9
Merged-In: I3d03b1e3897e427c23fbe51315f412c57a4ce9e9
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)
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
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
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
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
MeasureUnit.internalGetUnit() is a method on ICU MeasureUnit which is
used to construct and register MeasureUnits. Calling it from non-ICU
code makes future calls to MeasureUnit.getAvailable(type) return the
newly-created MeasureUnit, but that MeasureUnit will not be fully
supported by ICU (no translations, ...).
This code creates a MeasureUnit by calling a constructor reflectively to
avoid the registration, which is a workaround.
The correct long-term fix is for ICU/CLDR to support petabyte correctly
(http://bugs.icu-project.org/trac/ticket/13355) and for us to just use
that instead.
Bug: 65632959
Test: bit CtsIcuTestCases:android.icu.dev.test.format.MeasureUnitTest
Test: coretests android.text.format.FormatterTest
(cherry picked from commit aa5629e608)
Change-Id: If18dd378668a59a700030856573e46917a1bd051
TYPE_TEXT_FLAG_NO_SUGGESTIONS is just a hint and does not mean
IME should never show a UI to display suggestions.
This CL makes that point clear in JavaDoc.
Test: checkbuild
Bug: 35875399
Bug: 38139781
Bug: 38184682
Fixes: 65693181
Change-Id: Id0c3b6bc05689a5f1c8b52637664f59d45850a60
Previously we added mMaxLineHeight to track the line height at the
maxLines value. However when maxLines is set to zero, mMaxLineHeight is
not calculated and remains 0. When maxLines is set to zero, the capped
height of the layout should be 0.
Test: Added a test case to coretests/StaticLayoutTest
Test: bit FrameworksCoreTests:android.text.StaticLayoutTest
Test: bit FrameworksCoreTests:android.text.DynamicLayoutTest
Test: bit FrameworksCoreTests:android.text.StaticLayoutLineBreakingTest
Test: bit FrameworksCoreTests:android.text.StaticLayoutBidiTest
Test: bit FrameworksCoreTests:android.text.StaticLayoutTextMeasuringTest
Test: bit FrameworksCoreTests:android.text.StaticLayoutDirectionsTest
Test: bit CtsTextTestCases:android.text.cts.StaticLayoutTest
Test: bit CtsTextTestCases:android.text.cts.DynamicLayoutTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Bug: 64822158
Change-Id: Id9240ee7b893f8af9cd0d91329617c24da80c7d2
Merged-In: a8d982d6c8
(cherry picked from commit a8d982d6c8)
StaticLayout.mEllipsized and mMaxLineHeight was set for proper
calculation of static ellipsized text height. However, since
DynamicLayout uses a static instance of StaticLayout, and nobody reset
the mEllipsized, this caused configuration discrepancies for different
DynamicLayout instances.
Test: bit -t CtsTextTestCases:android.text.cts.DynamicLayoutTest
Test: bit -t CtsTextTestCases:android.text.cts.StaticLayoutTest
Bug: 64372088
Change-Id: I8ea6697d29da2ccbb433b64f17b4d1d6f254e8e1
Merged-In: a19cd51d2c
(cherry picked from commit a19cd51d2c)
In I021ff2a97a60396fb1b6e4940d91d3cd6ccb6196, new API for
InputFilter.AllCaps was added. It accepted null as input. This CL
changes that so null locales would be rejected.
Test: bit CtsTextTestCases:android.text.cts.InputFilter_AllCapsTest
Fixes: 64261334
Bug: 37222101
Change-Id: Ic87942c3f341f71bc3c1c833b52ea3e751461e47
Resources.getFont may load other package's font. Stop loading font
resources unless the developer allowed to do so.
Bug: 64115349
Bug: 35763094
Bug: 62813533
Test: bit CtsTextTestCases:android.text.style.cts.TextAppearanceSpanTest
Change-Id: Ifa1b57a70650ba086b38407c0ed5b4048983e7e5
This reverts commit 0d253e46aa.
The original CL changed Typeface internal methods and broke
TypefaceCompatApi26Impl in support library which uses reflections.
Ideally, TypefaceCompatApi26Impl must fall back to public API
implementation but due to lack of method availability check, it ended up
crashing the application.
The original patch didn't change any behaviors in MR1, so reverting
that change is the best solution for MR1.
Bug: 64033594
Change-Id: Ie86afeb1b809e57915d62c1db5a70c8d210d2354
Test: N/A
To be able to parcel/unparcel Typeface, keep it in static context.
Bug: 62850669
Test: Manually done
Test: bit CtsTextTestCases:android.text.style.cts.TextAppearanceSpanTest
Change-Id: I408cd33b98d8bb13776560231d1eeaac0a7c6bf8
(cherry picked from commit c49ee3bde9)
Also clean up lower-level drawing of strike-through in Cavas.cpp.
We still cannot use the strike-through information from the font
since Skia doesn't provide it, so we are going with the default
values.
Test: Manual
Test: bit CtsTextTestCases:*
Test: adb shell am instrument -w -e package android.text com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 32907446
Change-Id: Iee6f8102a35eba0ff4127dbbef189529ab573e6d
Use ICU's MeasureFormat to the degree possible for formatting file
sizes.
Bug: 36994779
Test: adb shell am instrument -w -e package android.text com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: bit CtsTextTestCases:*
Change-Id: I4ad3b568ae7585b6ff56fddb79ded7c5b2118176
Introduce new attribute "fallbackFor" to font element.
By specifying name of the family to this attribute, that font is used
when the developer specifies the font family.
For example, if fonts.xml has the following family entry,
<family lang="ja">
<font fallbackFor="serif">NotoSerifJP-Regular.ttf</font>
<font>NotoSansJP-Regular.ttf</font>
</family>
the Japanese text is rendered by NotoSansJP-Regular.ttf by default.
Then, if developer specifies fontFamily="serif" in TextView, the Japanese
text is rendered by NotoSerifJP-Regular.ttf.
Bug: 37328609
Bug: 31491668
Test: bit FrameworksCoreTests:android.graphics.TypefaceSystemFallbackTest
Change-Id: I2744db7384c8056795e841c88b387545434131f4
