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
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)
Bug: 67609167
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.logging.SelectionEventTest
Change-Id: Ib5af1ec80a38432d1201fbc913acdc3597d6ba82
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
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
This is based on feedback on Ib5af1ec80a38432d1201fbc913acdc3597d6ba82
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
Change-Id: Ic8d58acb2bbd63cedcac4aa16940b4ac852aadc8
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
