Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
This CL also adds a test to ensure that a pointer source is used by
default when obtaining a MotionEvent, and that offsets are only applied
to pointer sources.
Bug: 207251886
Test: atest MotionEventTests
Change-Id: Id40accc6d1238c940f139a18b26fa277dd6e11f9
This is a follow up CL to our previous CL [1], which had an off-by-one
bug when determining the return value of
EditableInputConnection#endBatchEdit().
According to the API document of InputConnection#endBatchEdit(), the
following test should pass.
EditText editText = new EditText(context);
EditorInfo editorInfo = new EditorInfo();
InputConnection editableInputConnection =
editText.onCreateInputConnection(editorInfo);
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.beginBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isTrue();
assertThat(editableInputConnection.endBatchEdit()).isFalse(); // (*)
assertThat(editableInputConnection.endBatchEdit()).isFalse();
However, the last assertion marked with (*) actually fails due to an
off-by-one bug. This CL finally fixes it.
The risk of app compat breakages because of fixing this long standing
bug is supposed to be low, mainly because:
* the system has not relied on this return value yet.
* Widgets like WebView have correctly implemented this API.
* IME has always received true no matter what the app returned, which
is the same behavior as other async InputConnection APIs.
This CL adds several notes to InputConnection#endBatchEdit() document
to help developers correctly implement and use this API.
[1]: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
c478c171e9
Fix: 209958658
Fix: 210165648
Test: atest -c CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
Merged-In: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a
(cherry picked from commit beda2b7f76)
Fixes a case where the SurfaceView is stuck with a wrong
scale.
Destination frame scales the buffer to the SurfaceView
fixed size. Currently the initial destination frame is
applied when the first buffer is acquired by BBQ. The
transaction is sent via the BBQ apply token.
Meanwhile if the client updates the SurfaceView fixed
size, the SurfaceView will apply the transaction via
the SCC apply token.
This can cause destframe changes to be applied out of
order causing the app to be stuck with the wrong
scale.
Bug: 195443440
Test: atest BLASTBufferQueueTest
Test: repro steps from bug
Change-Id: Ibf53a0efdebb87291d081e48633c373a98d347b1
Merged-In: Ibf53a0efdebb87291d081e48633c373a98d347b1
The system received the same multiple translation responses in a very
short time. We use a isShowingTranslation flag to determine if the
duplicated responses to call onShowTranslation. However the
isShowingTransation flag is set in a post runnable, this may cause the
system allow the duplicate responses can call onShowTranslation
because the isShowingTransaltion isn't set true yet.
Use multiple flags isShowingTranslation and a new isRunningAnimation
to check if the same translation response should skip to call
onShowTranslation.
Bug: 207457172
Test: manual
Test: atest CtsTranslationTestCases
Change-Id: I7003b7f49fc0a8ce2e909228bcb89acedee6d3d0
We may set a z-order different from the prefix order, for example
TaskDisplayArea#adjustRootTaskLayer. As a result, we should no longer
set animation leash layer based on the prefix order.
Fix: 208793409
Test: manually test launching activity over another
Change-Id: If8d545ca7a9ac42162262ad3a8f95b4ac9f65585
EventLog function can handle string,integer class and long class. (in android_util_EventLog.cpp)
If menu title string are used bold tag(like <b>test</b>), it'll be android.text.SpannedString.
therefore any android activity using tag menu string(like <b></b>) can be crashed by IllegalArgumentException.
Bug: 208862322
Change-Id: I2432b0cd28c8f5fcb07cdf3e29560bf6b6c0f7b6
Signed-off-by: chenchaoli <chenchaoli@xiaomi.com>
There are missing API description at getServiceComponentName in
ContentCaptureManager. Some errors may occur and an exception may be
thrown. So update the javadoc to remind user to handle.
Fixes: 203368373
Test: make
Change-Id: I979c81c74cda4e50627dc0c83ae7c33b333b9255
Fixes an issue where getting the IME source to check its
visibility unintentionally lazily created it.
Fixes: 208200189
Test: manual
Change-Id: Ib36082b393215fc59e299dea30d3315f3748ca02
The previous code waited for a frame complete callback from hwui before
notifying WMS that a draw had occurred. However, frame complete callback
was not guaranteed to get called since it only invokes a callback if a
draw actually occured. VRI really needs a signal that RT has completed,
since it just needs to know that a draw was possible so it can notify
WMS that the RT completed its pass.
Instead, rename frameCompleteCallback to frameCommitCallback since that
API is exposed to a public API when a frame was actually drawn.
Create a new callback, frameCompleteCallback, that is invoked when the
draw has completed, regardless if a frame was actually drawn.
When the frameCompleteCallback is invoked, VRI can check to see if a new
frame actually drew. VRI can call into BBQ to see if the frame acquired
matches the frame that was attempted to draw. If so, VRI can wait on a
transaction callback. If not, it can allow VRI to continue. In either case,
it will notify WMS that the draw has finished.
Test: Split over and over
Bug: 195262673
Bug: 193634619
Change-Id: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
Merged-In: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
CL[1] using isRequestedVisibleAwaitingControl() in
ImeInsetsSourceconsumer#setControl to hide IME surface when it returned
false without waiting control or requesting visible to deal with the
unexpecting hide IME cases during the testing.
However, when calling IMM#toggleSoftInput to reqest showing keyboard
on the dialog implicitly that will set requrested visible on both the
caller window and the dialog window, since toggleSoftInput didn't
explicit set the target window but just using the caller window as
requester implicitly.
It causes a regression that can't hide the IME surface when dismissing
the dialog to back to the caller window that the IME insets source
control is null but isRequestedVisibleAwaitingControl still returned
true because isRequestedVisible has been set true for the
toggerSoftInput caller window.
Revert logic in setControl to use mIsRequestedVisibleAwaitingControl
in case the IME surface won't be removed when backing to the implicit
caller window of toggleSoftInput.
[1]: I3071af14bf78e23f9526d6a9c138ab6ae2e0e339
Bug: 207092186
Bug: 204524304
Test: manual
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: Ic5265a6c3f2eba77d43832d23309998bf3cb1671
