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
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
