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
Changes unfold overlay implementation from a window
to surface control view host. To make sure that the
unfold overlay is drawn by the time when we remove
screen blocker we synchronously apply a transaction
with drawn overlay and apply another empty transaction
with vsyncId+1.
Also these changes disable the unfold transition when
using power button by filtering only first screen turning
on events after unfolding the device.
Bug: 197538198
Test: manual fold/unfolds
Test: killing SysUI process, checking rotation animation, magnification
Test: atest com.android.systemui.unfold.updates.DeviceFoldStateProviderTest
Change-Id: I8e0bc635b041595602145b313548b14fcabd157e
DisplayInfo (current and non-current display)
Changes behaviour from dumbly applying the insets of the current
DisplayInfo to all other DisplayInfo, to reading the insets of each
DisplayInfo into WindowMetrics. Additionally, applies the appropriate
rotation to the insets of each DisplayInfo, so the WindowMetrics
contain the correctly-rotated insets.
Bug: 201546646
Test: Manual
Change-Id: I5756a768b7544939d55d5759f838b27278ca1da6
Launcher needs to be able to customize the task transition to:
1. set the background color during task transitions to the taskbar color when the taskbar is visible.
and, temporarily, at least until tasks have rounded corners rather than being an overlay in the taskbar, we need:
2. a way to specify how much to crop the task by so that the task's rounded corners are visible above the taskbar during animation
3. a way to specify how much to crop the taskbar by so that the taskbar's rounded corners overlay is not visible over the tasks during the animation
Test: None
Bug: 200675009
Bug: 196387647
Merged-In: Ifb7f89e7fde47155eb987161fbbe30e7144103ab
Change-Id: Ifb7f89e7fde47155eb987161fbbe30e7144103ab
NDK exposes ANativeWindowTransform/NATIVE_WINDOW_TRANSFORM_*. These
constants are aligned with HAL definitions and are used internally to
specify buffer transforms. Native consumers of the transform hint
are expected to generate ANativeWindowTransform from the hint.
Aligning the SDK and the NDK transform values will make the API
less confusing.
Bug: 196167822
Test: atest AttachedSurfaceControlTest
Change-Id: Ib20be045f6c8c6d7befef93a839a27098da55ffa
It is possible the developer calls pauseTranslation() to show the
original text but it calls startTranslation() to show translated
text. Ideally the developer should call resumeTranslation but it
also make sense to call startTranslation() to show translated text.
When receiving translation response, we avoid showing transaltion
if the view already has the response and it's the same. But it is
good to also check if the view is showing translated text or not.
If the view is not translated text, it is possible developer calls
startTranslation() instead if calling pauseTranslation() to show
translated again, the fixing can resolve this case.
The issue case can be fixed by this change. But there is a deeper
problem about it's useless the caller call finishTranslation(). This
is planned to be fixed in next release.
Bug: 201238016
Test: manual. The issue case is fixed.
Test: manual. Test some chat apps, it still works fine.
Test: atest CtsTranslationTestCases
Change-Id: I699d0fa1d60ac96db094adcc6e17f4203df03214
Use applyTransactionOnDraw to ensure all transaction happen
during the same frame, including
- hide the starting window.
- reparent the remote SurfaceView to client.
Bug: 198593932
Test: continues launch test app several times then verify with winscope
to ensure there is no flicker anymore.
Merged-In: I03c600afdc477ca0c8064b215f2b361468db9f3c
Change-Id: I03c600afdc477ca0c8064b215f2b361468db9f3c
