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
It's already a noop, we just never cleaned up the
frameworks/base side.
Bug: 200285149
Test: Existing tests pass
Change-Id: I7d79404f93a9386b16fb9770bbd7290dfb236cc0
Revert submission 16003793-magnification_border
Bug: 196510717
Reason for revert: Caused NexusLauncherTests and NexusLauncherOutOfProcTests to stop running
Reverted Changes:
Ibbc9c51ea:Do NOT MERGE Fix magnification border includes tas...
Ida2bb5bf1:DO NOT MERGE Fix the cutout of magnification borde...
Change-Id: Id61a370271f94b4a379709226a90e29bc5dfa4b3
Before this CL, system dialogs would not react to configuration changes,
which would cause weird UI issues when folding into a smaller screen.
This CL makes all SystemUIDialog's listen for configuration changes, and
resize their window accordingly.
Bug: 204042506
Test: Manual
Change-Id: I4cf1dbfff2a95c83ed3e240d165eae60660c429b
This is to make sure that the task animation looks good and consistent
when the taskbar is and isn't visible
Test: Check task transitions animations look ok both when taskbar is and
isn't present
Bug: 200675009
Change-Id: I8ff70271a81dcdf329849907175691f901edc1d9
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
Change-Id: Ibbc9c51ead9ea492f1f2e598587b21dd28d30a2b
When testing testImeSwitchingWithoutWindowFocusAfterDisplayOffOnFull on
the virtual device, the test flows will be:
1) Launch an activity and click the editor to show IME
2) Turn off/on the screen
3) Launch the IME picker dialog and expecting no window focus change.
4) Switch to another IME app and expect the IME visible after switched.
Somehow the flaky point is in step 4) that if attaching the new input
to show the IME comes first, before the input target updated to WM,
in the meantime the app received onControlChanged
callback with null control from WMS#relayoutWindow, then in
ImeInsetsSourceConsumer#setControl -> hide() will end up calling
notifyImeHidden for IME to invoke hideMySoftInput(), which is
not expected result.
As this unexpected IME hidden issue is related the timing issue of
updating IME targets to WM a bit late and showing IME request happends
from IMMS instead of from ImeInsetsSourceConsumer#requestShow.
(i.e. consumer#hide() be invoked when mIsRequestedVisibleAwaitingControl
is false but the control is null when setControl called)
To fix this issue case, it looks make sense to check with
ImeInsetsSourceConsumer#isRequestedVisibleAwaitingControl() when the
null control callback in setControl(), since
isRequestedVisibleAwaitingControl() will be true when requested the IME
visible, so that it won't fall into hide() logic.
Also, modified "Animation finished abruptly." debug log in
InsetsAnimationControlImpl#applyChangeInsets to print only when the
animation actually finished, since it does not make sense to print
when the animation is not finish.
Fix: 204524304
Test: atest InputMethodServiceLifecycleTest#\
testImeSwitchingWithoutWindowFocusAfterDisplayOffOnFull \
--rerun-until-failure 100
Change-Id: I3071af14bf78e23f9526d6a9c138ab6ae2e0e339
Fixes the bug if the translation service spending more time to deal
with the translation but user switches back to original lauguage
quickly, we will show translated text.
When the response back, if the translation state is finished, we drop
the result. If the state is pause, we update the response but we do
not call onShowTranslation to translated text.
Bug: 200251777
Test: atest CtsTranslationTestCases
Test: manual. Try to send request late and switch back original
language, it keeps original. Then it works fine when switch between
the source and target languages.
Change-Id: I780456f091884c61e5801ead3ff021531fee87b4
Found a memory leak on ViewRootImpl. If the view wasn't been set
to the VRI successfully, there would keep the registed listeners to the
AccessibilityManager and DisplayManager forever because there didn't
need to deatch anything from window.
Another reasonable way is to register all listeners after setView
success.
Bug: 200843755
Test: manual, hard code to force addWindow fail and monitor no more
ViewRootImpl object leaked to AccessibilityManager and DisplayManager.
Change-Id: I3c9cc52d0ca4595c74c1dc3c51d286d9e6e3897f
