Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I9ad876043fd61f708a8f468fffd1ef371bfa0866
When disabling batching input, we should post the action to consume
batched events to prevent it would be handled before current event.
Bug: 189241600
Test: atest WindowInputTests --rerun-until-failure
Change-Id: I87aaa2574a27368f88df1aba3f2eb769a8e8f36b
(cherry picked from commit a0ef47223c)
There is a flicker in wallpaper picker due to a recent change where
SurfaceView creation changes were synchronized with VRI frame. This
breaks wallpaper picker because wallpaper picker doesn't actually
draw into the SV surface, instead they attach a surface package.
The current implementation meant the SurfacePackage would be visible
before it was scaled correctly.
This fix applies the visibility changes along with the scaling changes.
Test: steps in b/211945947
Fixes: 211945947
Change-Id: I4e5107ac2caf634429e1bec3201fdcaa8f5f92bc
(cherry picked from commit 230677e7b3)
PositionUpdateListener callbacks maybe replaced before they
are applied. We need to merge with the existing transaction
so we don't drop any destination frame updates. But accessing
the previous callback transaction is unsafe since we might fight
with render thread.
Fix this by locking access to the transaction object.
This also fixes a potential SurfaceControl access issue where
we may release the SurfaceControl that is used by render thread
in the UI thread.
Fixes: 211090247
Test: atest SurfaceViewSyncTest
Change-Id: I28ed344754601169c6cefd919668e76ef5a467c3
(cherry picked from commit 894fa8809a)
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
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
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
The insets resize animation is used to produce the callbacks of the
animation progress to the app. It shouldn't change the state of the
insets controller.
Fix: 205082601
Test: 1. Open a sticky-immersive app on a device which has taskbar.
2. Make sure taskbar is minimized on apps.
3. Swipe from bottom twice to go to home screen.
4. Open the same app again and see if task bar is hidden.
Merged-In: I5d9213d7b3e32eccbf3a51335654f5f53899e6ae
Change-Id: I5d9213d7b3e32eccbf3a51335654f5f53899e6ae
(cherry picked from commit cb11735c85)
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Bug: 205859784
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Test: atest NexusLauncherTests
Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
When hw rendering is disabled, we can't merge the transaction with the
next frame because the frame drawing callback won't be invoked. Instead,
just apply the transaction immediately
Test: HW Rendering app can remove SV
Fixes: 205924676
Change-Id: Ia6adb6dbad0238c4d815c72efc9b73bf4ea9c84a
The window type of the Taskbar is navigation_bar_paenel, which
is unmagnifiable. However, we used to exclude these windows from
magnification region computation to avoid cutout.
When the foldables is unfolded, the taskbar wouldn't cause the cutout.
To fix this problem, so we add a flag to distinguish the windows
that cause the cutout.
Bug: 196510717
Test: manual test
atest AccessibilityManagerServiceTest
Change-Id: I882bf48585f646cee5827044c88da37250041c0f
Merged-In: I882bf48585f646cee5827044c88da37250041c0f
(cherry picked from commit dc9b90f46a)
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Change-Id: Idd74da965c18bdbf8912bd45e89be21f652dcf93
Expose consumeNextDraw from ViewRootImpl to enable
one-off sync between two ViewRoots.
Bug: 201046726
Test: Existing tests pass
Change-Id: Iaf30830dc529eac83276a76d1908a06d12175b00
Since both of splitting tasks in split screen go to overview together
now, update to snapshot all pending animations when rotating while
showing overview to ensure both of splitting task snapshots are taken
with proper bounds before rotation.
Bug: 200813008
Test: atest RecentsAnimationControllerTest
Test: enter overview after activated split screen, observed task
thumbnails showing with correct bounds after roation.
Change-Id: Id1101bf8be67593f85a43c1d4afae769ffc737d3
When SV is detached, we will try to clean up the SurfaceControls.
However, we want the clean up to be synced with the main app window.
This is to ensure we don't remove SV's SC before the
app window draws in the hole punched area.
Instead of relying on postionLost to synchronize with the main app
window, we can use applyTransactionOnDraw to ensure the next frame will
merge the remove transaction. Therefore, we no longer have to call
remove in positionLost since it's already handled elsewhere.
Test: No flicker when removing SV
Bug: 199860472
Change-Id: I93a91c45c862949e53ee9fd1b4a3b10404fba6bb
Otherwise, there will be NullPointerException.
Fix: 204883084
Test: Run the following code and see if it crashes.
ViewGroup v = new FrameLayout(context);
v.requestTransparentRegion(v);
getWindowManager().addView(v, attrs);
getWindowManager().removeView(v);
Change-Id: I059e13d2a258cf85dbc1694fb79b6088199de3fb
