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
Note that AppCompatTextView doesn't work well with this attribute since
it overwrites the selected Typeface.
Bug: 63135308
Test: atest android.widget.cts.TextViewFontWeightTest
Change-Id: I76ee5e3007ea5f96249d2a0bfb66ff5975c62522
When used on views with a dark background, the magnifier does not really
stand out from the view, which is potentially confusing for users. This
CL mixes the magnifier content with 5% white in order to make the
magnifier more prominent on dark backgrounds. Also, the CL increases the
elevation of the magnifier window, useful in light backgrounds.
Bug: 70608551
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I7c6e4418b49b7fe0d69344668fa66d39417b4ecc
Customization will be supported in the next release. This CL hides
the public API that is needed for customizing MediaControlView2.
Test: build
Change-Id: Ie8132f70f2dc5bc3fbcf73c1e39edd9d5f8cb3f6
Add APIs for getting/setting MediaMetadata2 in oder to add support
for Advertising media type.
Bug: 73136129
Test: run VideoViewTest.apk
Change-Id: Iab8e23c1f02f4e2df62a6732112b233541f8f35c
The CL adds synchronization around the InternalPopupWindow instance
used, between the main thread and the thread that handles pixel copy
results. This comes to fix a potential null pointer exception that
might occur after a #dismiss().
Bug: 73765118
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I8a8feb02f3ee418597ce3eee50db77b4b67e462e
The CL adds a TestApi callback mechanism which enables CTS tests to know
when magnifier operations have completed. This is required since
the magnifier is using an auxiliary thread (different from the main
thread) to do work.
Bug: 72041926
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I44f324297b63910d19d60bd7462e9aee8d8a4f3e
Previously, we would make a renderer draw whenever a pixel copy
completes. Because of this happening more than once per view frame,
magnifier frames were being dropped or queued up and displayed later,
which was consequently leading to the magnifier movement getting out of
sync with the updates to its content.
This CL changes the magnifier to be rendered from a draw job post'd to
the UI thread queue. This way, multiple magnifier updates (the ones
already pending in the UI thread queue when the draw job is added) are
batched together in a single draw, naturally rate-limiting the draws we
send to the magnifier renderer by the number of frames of the magnified
view - this only holds when the user of the magnifier sends updates as a
result of user interaction or when the magnified view is drawn.
Also, previously the pixel copy finished events were post'd to the UI
thread. Since they were not post'd as async messages, they would have to
wait at frame barriers before being executed. This CL creates a
dedicated thread for them to be post'd, to avoid this from happening.
Bug: 72041926
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I89563a341a74e958f903eff2d470c6c33fb203ef
A WindowId's token should never be null, but let's avoid getting into
that situation in the first place.
Fixes: 70015590
Test: manual, cannot reliably repro in CTS test
Change-Id: I378ba9ba822ecc445d3b8de265b5ec0d20a12dd3
Previously, if the magnifier was triggered when the cursor was invisible
between blinks, the cursor would remain invisible until its position
first changed as a result of user dragging. This CL fixes this, by
forcing the cursor to become visible when the magnifier is triggered.
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Bug: 72314929
Bug: 63531115
Change-Id: I95dd0c2474f1cd1695ff3083e062ee38867b8a0c
Since the movement of PopupWindows is handled by the global window
manager, using one does not provide synchronization guarantees between
the window movement and its view tree rendering. In the case of the
magnifier this was producing a shaky-text effect, when the window was
moved in one frame, but the content was only updated in the following
one (although the movement and content update were issued during the
same #show operation on the UI thread).
This CL abandons the usage of a PopupWindow for the magnifier, in favour
of a raw Surface whose movement can be controlled using the deferred
transactions API. This way, we can defer the surface movement until the
frame when the updated content is rendered. The allocated magnifier
surface is slightly bigger than the magnifier content to have space for
drawing the elevation. We obtain a native elevation by using a
RenderNode to draw the content of the magnifier.
Bug: 72041926
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Icb8ecf48a2f528e06790db95d54575f2ae119747
This is 2nd attempt of I7db9e2ca4db68a16648cfb8fcf63555f501304c2
This CL changes the MeasuredText API:
- Rename MeasuredText to PrecomputedText.
- Introduce PrecomputedText.Param which holds all text layout parameters.
- Add API to get PrecomputedText.Param from TextView.
- Remove MeasuredText.Builder and add PrecomputedText.create method instead.
- Remove setRange from MeasuredText since it is not for normal use case.
(It can not be used for TextView)
Bug: 67504091
Bug: 72861572
Test: bit FrameworksCoreTests:android.text.
Test: atest CtsWidgetTestCases:EditTextTest \
CtsWidgetTestCases:TextViewFadingEdgeTest \
FrameworksCoreTests:TextViewFallbackLineSpacingTest \
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest \
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest \
CtsTextTestCases
Change-Id: Ie73bce52c6c673cda58973ddad04627a7cf2e5e9
Previously, the TextClassifier only supported Activity intents.
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Ic488e2f6241eb91a6cd6e16d9f84a49a679164dc
Using the non-transformed text is bad because the
transformed text is what's actually on the screen,
so it is the thing whose position is relevant.
Bug: 69044691
Test: Updating a11y cts test to use an all-caps
german strong s, which causes the transformed text
to be longer than the original text. That changed
test fails without this fix.
Change-Id: Ia7aac3b4322ffb48f10771f4d1b33c80ca28b120
