The beforeText in a text changed event was coming from
the underlying CharSequence, not what was on the screen.
As a result, it was not sent for password fields. Now
we just provide whatever is on the screen, which is
obfuscated to the same degree it is for a user looking
at the screen.
Bug: 75324441
Test: Verified with password field in TalkBack sample app.
Also atest CtsAccessibilityServiceTestCases
Change-Id: Ib7a10313d2f9d0e44d2052e81e47f19967a67bc4
There is no point in displaying the magnifier when the text is large
enough. In this CL we are using the font metrics of the TextView to
decide whether the magnifier should be displayed or not.
Bug: 70608551
Test: manual testing
Change-Id: Icb2fb4412b6b930dfb3322e51fd0139152cf9d39
DynamicLayout is required when
- The text is Editable.
- The selection is enabled on TextView.
This CL stops using DynamicLayout when the TextView is not selectable
TextView and the input text is PrecomputedText.
Bug: 72998298
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ic4a66ad3ed8868570735e3199879b74132a8c4aa
1. Preserve selection when the TC times out. (See: SelectionActionModeHelper)
2. Fix highlight/toolbar flicker when tapping on a smart link.
- Highlight flicker happening because we reset the selection while in
the process of starting a link action mode.
i.e. onLinkDown: show highlight
onLinkUp: start the link action mode asynchronously
onLinkUp: reset the selection to an insertion cursor*
onLinkActionModeStarted: reset the highlight
*Fix: Don't reset selection while starting a link action mode.
- Toolbar flicker happening because the toolbar positions itself over
the current selection. The way link highlights have traditionally
been done is to set the selection to the links bounds*
*Fix: Hide the toolbar for a few milliseconds when changing
selection for smoother transition.
3. Fix Paste menu overriding link action mode toolbar after a recent
"Copy" action. The Paste menu appearing is a feature. Whenever the
user inserts a cursor after just copying some text, we show the Paste
menu as a way to make it easy for the user to select the text.
Because of the problem described in (2) above, changing the selection
to an insertion triggers the Paste menu feature. Fixing (2) fixes
this.
4. Fix IME popping up on non-selectable + focusable TextViews.
See: imm.showSoftInput(...) in Editor. And see comment in the code
around that. We should only pop up the IME for editable text.
Fixes: 73872461
Fixes: 75985239
Fixes: 76011461
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: If9ddb7f4e6d4db480ba4a495a22f7f2924ab937e
Before this CL, the magnifier window was sometimes displayed partially
out of screen or overlapping with the system bar. This CL prevents this
issue by clamping the magnifier inside its parent surface, also taking
into account the system window insets of this surface.
Also, the CL fixes two kindof unrelated small bugs:
- remembers to reset the previous show and pixel copy coordinates on
#dismiss()
- when clamping the pixel copy coordinates inside surface, consider the
size of the copied content rather than the size of the window where
this is scaled and then copied
Bug: 74234779
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iec3404123145aa95b37c88f4fbfa3918cbf24f9d
The flag should only ensure that smart linkify calls behave in the
legacy way instead of totally disabling linkify.
Also, to keep the flag consistent with smart_selection_enabled and
smart_text_share_enabled flags, the flag should only disable the
SmartLinkify (i.e. Linkify.addLinksAsync) feature not TextClassifier
APIs (i.e. TextClassifier.generateLinks).
Also fixes issue with non-focusable TextViews by firing the primary
action instead of showing the floating toolbar. (b/73156794)
Bug: 75967597
Bug: 73156794
Test: bit FrameworksCoreTests:android.text.util.LinkifyTest
Test: bit CtsTextTestCases:android.text.util.cts.LinkifyTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: manual - checked behaviour turning flag on/off
Test: manual - checked behaviour with TextView.setFocusableInTouchMode(true/false)
Change-Id: I541f60161b9cd63ce7e57235607500f2fb0841e7
This is 2nd attempt of I072dfd70b9a687d9c47e310d8cdb34f988fbb32e
The root cause of crashing is unexpected copying of NoCopySpan by
SpannableString constructor. To prevent crashing, stop copying
NoCopySpan by passing ignoreNoCopySpan=true to SpannableString
copy constructor.
The original commit message is following:
To support selectable TextView, make PrecomputedText spannable.
By this change, TextView start using DynamicLayout instead of
StaticLayout. DynamicLayout requires boundary rectangle of the
text, so this CL also adds getBounds method to PrecomputedText
which retrieves measured boundary box from native.
By this change, the selectable TextView performance for the
precomputed text 10x faster. On the other hand, the performacne
for the non-selectable text gets 2.5x slower. However, we concluded
that we accept this performance regression since it still 10 times
faster than non precomputed text.
Here is a precomputed text performance result of TextView.
android.widget.TextViewPrecomputedTextPerfTest:
newLayout_PrecomputedText : 736,130 -> 1,648,694: (+124.0%)
newLayout_PrecomputedText_Selectable: 17,379,765 -> 1,700,146: (-90.2%)
onDraw_PrecomputedText : 1,274,921 -> 1,848,076: (+45.0%)
onDraw_PrecomputedText_Selectable : 17,367,238 -> 1,399,169: (-91.9%)
onMeasure_PrecomputedText : 752,875 -> 1,766,606: (+134.6%)
onMeasure_PrecomputedText_Selectable: 17,647,842 -> 1,810,704: (-89.7%)
setText_PrecomputedText : 92,894 -> 135,471: (+45.8%)
setText_PrecomputedText_Selectable : 145,134 -> 215,757: (+48.7%)
Bug: 72998298
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ie98c75d8b4ba962eaf0a544357b2ff1ade891118
setupAutoSize fills in the possible text sizes that can be generated
between a min and max value. In order to do that, it counts the number
of steps starting from minSize until maxSize. However, while counting
it rounds the initial value, which causes rounding error at the final
step.
Test: Change system font scale to 1.1 via
adb shell settings put system font_scale 1.1
Test: atest android.widget.cts.TextViewTest
Bug: 73917559
Bug: 75266270
Change-Id: I61811db28ef01262bd48f5042d783d75c71c3614
(cherry picked from commit db86a6b047)
A couple of links were badly formatted. Updated doc staged to:
go/dac-stage/reference/android/widget/RelativeLayout.LayoutParams.html
Test: make ds-docs
Bug: 72624598
Change-Id: I197f5ef52f2476134db674d342dee812ceebec2a
Exempt-From-Owner-Approval: Doc-only change
This CL updates both the magnifier and the floating toolbar to use the
dialogCornerRadius attribute for the corner radius of their windows. In
both we use its value defined in the default device theme, rather than
the value defined in the application's custom theme.
Bug: 70848492
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ifcf4cff1f38fd18b7dbb4c1802390e3beb92cd3c
(cherry picked from commit 3dcbc2112d)
Merged-In: Ifcf4cff1f38fd18b7dbb4c1802390e3beb92cd3c
This is based on feedback on Ib5af1ec80a38432d1201fbc913acdc3597d6ba82
Bug: 74466564
Bug: 67609167
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.LoggerTest
Merged-In: Ic8d58acb2bbd63cedcac4aa16940b4ac852aadc8
Change-Id: Ic8d58acb2bbd63cedcac4aa16940b4ac852aadc8
Currently, for selection, if we move one handle towards the other, the
moving handle will stop when the selection becomes 1 character long.
However, the magnifier would continue to follow the finger after this,
no longer being helpful for the selection.
This CL fixes this, by replicating what happens when the magnifier
reaches the end of the line also for the case when it reaches the other
handle.
Bug: 72314536
Test: manual testing (both English and Arabic)
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I5bde622421c7fb8ecce0ea00f0d8d2af7aa72cf4
(cherry picked from commit 2d6b40b821)
Merged-In: I5bde622421c7fb8ecce0ea00f0d8d2af7aa72cf4
Currently, after the cursor is reaching the end of a line, the magnifier
keeps following the finger even if the cursor cannot move anymore.
This CL limits the movement of the magnifier, ensuring it stays between
the bounds of the text line. Also, when the finger gets too far from the
end of the line, we dismiss the magnifier. We consider it went too far
when the cursor is not visible anymore inside the magnifier.
Bug: 72314536
Test: manual testing (both English and Arabic)
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I8dafba1fc8e7b8e482526e818831ece2ee20ac27
(cherry picked from commit dfc752bc74)
Merged-In: I8dafba1fc8e7b8e482526e818831ece2ee20ac27
The CL exposes the size and the zoom of the magnifier in the public API.
These are required for implementing a number of UX requests in WebView
and Chrome - see the two bugs referenced.
Also, the CL fixes a bug in the #getContent() TestApi, which was
returning the bitmap before (instead of after) scaling.
Bug: 70608551
Bug: 72314536
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Idc583b923010d7dca075b05b6f4dbafa74cfec1f
(cherry picked from commit e1b93ddcbd)
Merged-In: Idc583b923010d7dca075b05b6f4dbafa74cfec1f
Being consistent, create route player internally and do not expose it
since VideoView2 creats a MediaPlayer inside and do not expose it.
Bug: 72527212
Test: manually with VideoViewTest
Change-Id: I6db3bc668f6ab77587fed49b2d34611bc3c30465
If SearchView is the first focusable, it will always get focus
(in non-touch-mode) when it tries to clearFocus on BACK pressed.
This lead to a situation where SearchView always consumed the
BACK key leaving users unable to leave some activities.
It looks like this was done so that pressing back both closed the
auto-correct popup AND the ime (whereas without reimplementing
onPreIme, it would require 1 back-press to close the auto-correct
popup and then a subsequenty press to close the IME). It also,
however, tried to clearFocus as well.
This change only consumes the Back press if the auto-correct popup
is open (to have the same effect of BACK closing both the popup
and the IME at the same time). It ignores the back press otherwise.
If there is no pop-up, this results in the BACK being handled by
the ime and thus hiding it. Otherwise, back is not consumed.
The only effective difference is that the SearchView remains
focused now.
Bug: 73181998
Test: SearchView CTS tests still pass. Back can now exit test-app
once IME is hidden.
Change-Id: I3fe687b5344300b86131f44a1c9798cd736955bd
If the given precomputed text is not compatible with the TextView,
reject the text by throwing IllegalArgumentException.
Bug: 73091756
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: I4fbf89a5f1409e8eefdeb9f208f9a3758220fe1a
(cherry picked from commit 3a0787af5e)
This reverts commit e77386e8fb [1].
Reason for revert:
The protocol is not yet ready to be exposed and we are still unsure
what is the best approach.
[1]: Ie86edafd1ed68b58f702116f561fc448fdbb57a8
Bug: 7031513
Bug: 72522601
Fix: 74087970
Test: atest CtsInputMethodTestCases
Change-Id: Ia61dc9b3d5b116199382994430fb16ee804942b3
Id65a7e36487375f0e3a2c2da44ad8d7c5ea49734 changes the typeface
associated with the TextView. It used be null if no attribute was set,
but after above change, it is now Typeface.DEFAULT.
The typeface is null means Typeface.DEFAULT but there is an expectations
in CTS that getTypeface must return null if no attribute was set.
To keep this behavior, call setTypeface with null if no font weight value
was set.
Bug: 74080879
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
Change-Id: Ic91827bbeed8a3a4b148dd8d305c78e384407ab0
In NotificationManagerService#cancelToast we have been calling
WindowManagerService#removeWindowToken with 'removeWindows'=true. This
is allowing for Surface destruction without any sort of synchronization
from the client. Before the call to removeWindowToken we are emitting
a one-way hide call to the Toast client. As a solution to the lifetime
issue we have the client callback to let us know it has processed the
hide call (and thus stopped the ViewRoot). On the server side we also instate
a timeout. This mirrors the app stop timeout. All codepaths I could find
leading to this sort of situation where a client is still rendering
in to a toast following the total duration expiring seem to indicate a hung
client UI thread.
Bug: 62536731
Bug: 70530552
Test: Manual. go/wm-smoke
Change-Id: I89643b3c3a9fa42423b498c1bd3a422a7959aaaf
Also updates flags list.
Bug: 72946306
Bug: 72946123
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationConstantsTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: I8af9d3d1da01836fbadcbbf6ce7c1c0db7456a05
