The bounds animation is cleaned up within window manager and it's now
the SysUI component listening on callbacks from TaskOrganizer for
entering to and exiting from PiP mode.
Additionally, the expand and move of the PiP window is now part of SysUI
as well.
Known issues:
- Black background when in transition from PiP to fullscreen. The
wallpaper gets into hidden state too early
- App gets into PiP mode too early when entering PiP, need to defer the
configuration change sent to app in this case
Bug: 146594635
Bug: 148198539
Bug: 138144750
Bug: 149569903
Test: atest PinnedStackTests
Test: atest PipAnimationControllerTest
Test: atest RecentsAnimationTest
Test: atest RecentTasksTest
Test: atest com.android.server.wm.ActivityStarterTests
Merged-In: Id0c8ce03fa26952daf5e3687b18b2eb2375b7d20
Change-Id: Id0c8ce03fa26952daf5e3687b18b2eb2375b7d20
The interaction between Java and native code for KeyEvent and
MotionEvent is different, so I used different arrangement to pass
sequence number across JNI that keeps the consistency with other
metadata.
Unfortunately this new ID doesn't have absolute uniqueness guarantee so
it can't replace InputEvent#getSequenceNumber() which is used with a
strict in-process uniqueness assumption. Therefore only convert systrace
related use to ID.
Also expose ID generator through a static function in InputEvent so that
everyone can use it. InputReader and InputDispatcher will use different
instances.
Bug: 144889238
Test: Build and run.
Test: atest FrameworksCoreTests:KeyEventTest
Test: atest FrameworksCoreTests:MotionEventTest
Change-Id: Icbdcaee1d98948c05484865a4e15e55161ecfa69
Merged-In: Icbdcaee1d98948c05484865a4e15e55161ecfa69
(cherry picked from 29d21d4062)
Right now it crashes because the ViewRoot expects to receive a
BLAST surface but the WindowlessWindowManager doesn't support it.
Adding support should be relatively trivial (coming in a follow-up)
but we haven't tested it yet so suggesting merging this patch for
today.
Bug: 150000636
Test: Existing tests pass
Change-Id: I4b36d190c8f4f022dada656e02452034113a4000
(cherry picked from commit b4727e0f55)
KEYCODE_BACK was previously hardcoded as a wake key in KeyEvent.java.
For TV remotes, we want to make this behavior configurable.
Test: Tested on Android TV Device.
Bug: 144979700
Change-Id: I496c9c283525d5e04325e4bb3d6ab19a571db0c7
Update document to notify that reported size is different between
WindowMetrics#getSize and Display#getSize and provide a sample
code to transform between usages.
Test: build & run
Bug: 128338354
Change-Id: I06aee9aaf903c3864fbb0fe89ea1d3e15506fe1c
(cherry picked from commit 2de0f42d50)
This reverts commit 288e1bd045.
The previous implementation of computeWindowInsets is to
use last view from WM#addView, which may be invalid because
the last added view is removed and throws NPE when getting
property from the invalid view.
In this CL, we change the approach to always obtain window
insets from server.
fixes: 148789183
fixes: 149480577
Test: atest FrameworksCoreTests:WindowMetricsTest
Test: atest WindowMetricsTests
Change-Id: I6db5970d14ac9eebe0ab0df65cb1300515ad1754
(cherry picked from commit 6bb2d4f68c)
Use getBoundsOnScreen without clipToParent instead since the bounds
may be out of screen.
Bug: 149539748
Test: a11y CTS & unit tests
Change-Id: Ie2107f58a7cc5f0b76e4a468cfb295c410dbb559
Merged-In: Ie2107f58a7cc5f0b76e4a468cfb295c410dbb559
(cherry picked from commit 9a341abdb4)
Introduce IWindowToken to report config/display changes from
server side. When config change callback is received,
it will update the resources associated with the window token.
Test: WindowContextTests
Bug: 128338354
Bug: 146820733
Change-Id: I871bd78a21dbde1286786e65c340b6259b873660
For compatibility reasons, we would adjust layout params before it is
sent to window manager. We need to adjust it after soft input mode is
set.
This CL also makes sure that only match-parent-non-attached-app window
can use FLAG_FULL_SCREEN to hide status bar. This aligns the logic in
the legacy insets mode which only allows mTopFullscreenOpaqueWindowState
using FLAG_FULL_SCREEN to hide status bar.
Fix: 149816539
Fix: 149822806
Test: Go to Developer options > Click on Smallets width, and see if the
layout of the dialog is correct.
Test: Long press power button and see if the dialog hides status bar.
Change-Id: I46daa0906bac981ccadb5f98aeb8b0479d23820e
This is to enable landing the SysUI driven PiP animation without BLAST. Without
BLAST we can't support multi container sync, multi buffer sync, etc, but we can
support the same sort of synchronization we've supported before. Let's recall how
the old PIP animation works: At the end of the enter animation, or the beginning
of the leave animation, the Surface changes size (When the Windowing mode changes).
We detect this size change deep in the guts of WindowStateAnimator, and when
we detect that we are called from "relayoutWindow" defer a transaction changing
the PIP scaling factors. This approach is we simply allow SysUI to set a pending
Transaction on a task via the WindowContainerTransaction API. The next BASE_APPLICATION
window to resize in this task will consume this transaciton, and defer the transaction
until the frame in which it resizes.
Bug: 139371701
Bug: 139371701
Test: Manual test with pending SysUI branch
Change-Id: I1e757d87e2f276db626de00685b0432508ac6d62
Make obtaining a visual service from non-visual Context instance
report a strict mode violation and print the stacktrace.
Make calling getDisplay() throw an exception if called on an instance
that is not associated with a display. For existing usages introduce
a new internal method that does not perform the verification until
the usages are properly fixed.
Bug: 128338354
Test: StrictModeTest#testIncorrectContextUse_GetSystemService
Test: StrictModeTest#testIncorrectContextUse_GetDisplay
Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
As tracked in Bug 28750507, InputMethodManagerService#onSwitchUser()
is known to be slow, and the direct reason of the UI jank in the
launcher discussed Bug 139806621 is that #onSwitchUser() is running as
part of IMMS#startInputOrWindowGainedFocus() that is called as a sync
IPC from the UI thread of the launcher. Note that this is a
relatively new behavior that was introduced in Android 10 to support
per-profile IME mode (Bug 111083076). So users shouldn't see this code
path unless the device is running on Android 10 with work profile
enabled.
What this CL does is removing that direct code path from
IMMS#startInputOrWindowGainedFocus() to #onSwitchUser() by introducing
a new pending result
InputBindResult.ResultCode.SUCCESS_WAITING_USER_SWITCHING,
which means
IMMS is now performing user switching and cannot start input session
right now, but it will call the client back when the IME becomes
available for the target user.
Note that InputMethodManager is already able to handle this kind of
pending state, where IME is not yet available, since we already have a
similar pending results as follows.
* InputBindResult.ResultCode.SUCCESS_WAITING_USER_SWITCHING
* InputBindResult.ResultCode.SUCCESS_WAITING_IME_BINDING
One remaining concern is that when IMMS#switchUserOnHandlerLocked() is
running with holding the giant lock (IMMS#mMethodMap), thus it's still
possible that IMMS#startInputOrWindowGainedFocus() can be blocked
because of lock contention, which eventually blocks client's UI
thread. Although its chance wouldn't be that high, in order to tackle
that scenario we need to pursue different approaches such as:
* Further optimize IMMS#startInputOrWindowGainedFocus() to reduce the
likelihood of lock contention. This isn't a perfect solution for
this particular case but it's still worth doing. Possible
candidate of optimizations are:
* Bug 28750507: optimize IMMS#switchUserOnHandlerLocked()
* Bug 149864769: off-load Context#unbindService()
* Reconsider the use of giant lock.
* Redesign the current "startInput" protocol as part of our on-going
effort to redesign IME focus handling protocol (Bug 141738570)
e.g. can we completely make IMMS#startInputOrWindowGainedFocus()
async IPC?
Bug: 139806621
Fix: 144291210
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: Manually made sure that IMMS#startInputOrWindowGainedFocus()
isn't blocking Launcher's UI thread when swiping home.
1. lunch aosp_coral-userdebug && make -j
2. Flash the image
3. Open the system settings
4. System -> Gestures -> System nagivation
5. Select "Gesture nagivation"
6. Install Test DPC.
7. Enable managed profile with Test DPC.
8. adb install -r \
$ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
# deal with dex2oat
9. adb shell cmd package compile -m speed \
-f com.google.android.inputmethod.latin
10. adb shell cmd package compile -m speed \
-f com.android.inputmethod.tools.edittextvariations
11. adb shell cmd package compile -m speed \
-f com.google.android.apps.nexuslauncher
12. adb root
13. adb shell setprop pm.dexopt.disable_bg_dexopt true
14. adb reboot
15. adb shell am start -u 10 \
-n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
16. Tap the first edit text on the EditTextVariations
17. Make sure that AOSP Keyboard is shown
18. adb shell am trace-ipc start
19. external/chromium-trace/systrace.py \
gfx freq am wm sched binder_driver view \
-a com.android.launcher3 -o binder.html
20. Swipe up the home button
21. Hit the enter key to terminate the systrace.
22. Check the IPC log to see how much the UI thread is blocked by
IMMS#startInputOrWindowGainedFocus()
Change-Id: I5a73a66d2b8acadad9b3577ebc4c17b5a25fd011
* The bundle will be generated/consumed by the support library.
* More API documentation and example usage will be added later once we have the support library impl ready.
* The old style resource name approach doesn't work due to the potential mismatch in the support library version across the host IME and the platform renderer service, and the non-static nature of the public attribute int id in the support lib.
* The Bundle added to the onCreateInlineSuggestionsRequest() is intended for the platform/ExtServices to communicate the UI versions it supports.
* The Bundle added to the InlinePresentationSpec is intended for the IME to communicate the custom styles for the chosen UI versions.
Test: manual verification, and also atest CtsInputMethodTestCases:InlineSuggestionInfoTest CtsInputMethodTestCases:InlineSuggestionTest CtsInputMethodTestCases:InlineSuggestionsRequestTest CtsInputMethodTestCases:InlineSuggestionsResponseTest
Bug: 146454892
Change-Id: Id7fea32a7550fb924fec811b376790474a7b92eb
MotionEvents sent from InputDispather would be buffered and dispatched
align the vsync by default. And it would provides many of benifits.
But for a high quality gaming experience, low latency input is critical
when we use analogs inputs (e.g mouse or joystick, etc.). So It's
important for gaming applications to process these input events in a
raw way, without them being coalesced on each frame.
- Add new api View.requestUnbufferedDispatch(source) to control which
input source classes could be unbuffered while handled by the view.
Bug: 135740001
Bug: 136277595
Test: atest ViewUnbufferedTest
Change-Id: If65ed1906f59947dcd1e5062519b643a17d0e8e5
if the specification contains all of left, top, right, and bottom bind
cutout, the bottom cutout rect return null. But, it should be non-null.
The specification that contains bottom right corner cutout assigned to long
edge in phone like device can't be achieved. But, it should be achieved.
Test: atest \
FrameworksCoreTests:android.view.DisplayCutoutTest \
FrameworksCoreTests:android.view.CutoutSpecificationTest \
SystemUITests:com.android.systemui.ScreenDecorationsTest \
CorePerfTests:android.view.CutoutSpecificationBenchmark
Fixes: 149675352
Change-Id: I6c742f93e72627f1d58b8ce971a4b1cc9792d5cf
According to the logic in #isImportantForAccessibility, SurfaceView
wouldn't be important by default. This results in the A11yNodeInfo
generated by this SurfaceView isn't important. If this SurfaceView
hosts an embedded hierarchy, the accessibility services may ignore
it. Hence, it couldn't compose the complete node tree.
Bug: 149266686
Test: a11y CTS & unit tests
Change-Id: I90d9f043339d2ad72607e8ae8c8dfc2c1b0f004d
Use the early TaskOrganizer concepts to implement Split-screen
in system-ui.
This includes changes to both FW and SystemUI. The changes to
FW involve removing the use of split-screen specific behavior (like
minimize dock and direct ordering) and also reducing things that
care about primary vs secondary. It also changed ActivityStack
to inherit bounds from parent** when in split-mode so that sysui
only needs to manipulate the tile and/or reparent stacks to
effect their geometry.
This means a lot of layout logic moves to SystemUI. The bulk of
the work done in ActivityStack which is split-screen related is
moved into SplitDisplayLayout. This basically takes a snapshot of
display configuration and manages the sizes of splits and their
snap targets.
Intermediate dragging of divider bar now only moves root task leashes
around rather than talking to WM. This includes position as well
as crop (which used to be stack crop). Once the user releases
the divider bar, it will calculate (based on snaps) the new
root task sizes and update their configurations via
WindowContainerTransaction. Because the interim updates are only
on the leashes, no configuration updates occur until the end.
Entering/Exiting split-mode is now handled by SplitScreentaskOrganizer#
onTaskInfoChanged. This is effectively a state-machine that
looks at the current split task membership vs. previous and then decides
when to move things into/out-of split tasks and how to coordinate with the
DividerView.
Minimized dock is relegated to a purely system-ui concept. To
accomplish this, **the home *stack* is set to the minimizedhomebounds
by systemui. This means that it's relative position to its parent is
negative! This allows us to leave the split sizes constant, have
their children inherit the "actual" split sizes, but keep the
home stack unchanging in its minimized size. We just adjust the crop
negative to reveal it.
IME handling is done through the same mechanism as app-driven IME
animation... only Divider receives the control instead of the app.
This allows synchronized animation of split tasks with IME. To
account for insets, though, when IME is opened, the bottom stack
will be repositioned in WM.
Bug: 133381284
Test: Manual, use split-screen, rotate device, launch unresizable
apps in split, use divider snap to close/maximize apps, etc.
Change-Id: I7133e151a1037c42b275b97857936437a7a6725f
When the SurfaceView is moved, we need to detect this and trigger
the ViewRootImpl to use a BLASTSync transaction for the next draw.
First we tried to do this from invalidate but parent invalidation won't
always lead to invalidate and so this doesn't work. Doing it from
updateSurface which is called from a PreDrawHandler ensures we
will be evaluated at least once per draw.
Bug: 146598493
Bug: 149251083
Bug: 149315421
Test: Flip the flag. Play with youtube.
Change-Id: I652eacf1a016f8b65fd754e47d468227bf8ecf1d
...such that we don't trigger another apply immediately after
the first frame.
Test: Launch calc, observe only one onApplyInsets
Bug: 148604688
Change-Id: I1b8c1735ca0b93869eb3bf8bd1fc078e6474e653
