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
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
Currently we aren't well equipped to handle overlapping synchronization.
That is to say where a second BLAST Sync begins before the first one finishes.
We track enabling this in b/149747443. In the mean-time we take a few steps
to prevent overlap:
1. Call finishBLASTSync directly from the RT callback rather than posting
to the UI thread.
2. Before consuming "mNextDrawUseBLASTSync" fence the threaded renderer to make sure
any previous draw has finished and emitted its callback.
3. Use seperate variable for tracking whether the BLAST transaction has been applied
so that an earlier draw finishing inbetween us calling setNextDrawUseBLASTSync
and calling performDraw, will not lear the value of mNextDrawUseBlastSync.
Test: Flip the flag, play with youtube.
Bug: 149747443
Bug: 146598493
Bug: 149251083
Bug: 149315421
Change-Id: I6cfd976cd72345acc814fc99d182b50456014a0e
These won't work with the BLAST adapter since the Surface isn't
known to the server side. We just convert them in to the other
variant of defer transaction calls.
Bug: 146598493
Bug: 149251083
Test: Existing tests pass
Change-Id: I34fc4bb90114bae8b0d9ffdee5c91a2371e5c240
DeviceProductInfo API that can be used to prime an Android TV remote
with entries from an infrared database for controlling connected
audio and TV devices. See go/display-identifiers.
Bug: 145299597
Test: adb shell dumpsys display
Change-Id: I8d709d55d830eed932b51bb8c374d32e20eecf6d
* The extra can be used to indicate the UI rendering library version, as well as anything else we may need after API freeze
* Also make the style in InlinePresentaionSpec publically accessible
Test: build
Bug: 146454892
Change-Id: Iaaf66c2dcffdef3ef8e91c347774afa3aa6176f9
Fixes issues the app developers have raised with
the WindowInsetsAnimation API:
- it really makes more sense to have the Animation
as the outer class, and the Callback nested within
- it was not obvious previously that multiple animations
could be running at the same time. A new argument to
onProgress now makes this abundantly clear by passing
in the list of running animations.
- The dispatch mode really fits better as a final
property on the callback, rather than it being
queried once from a getter.
Also fixes lint warnings.
Fixes: 143556682
Test: make checkapi; atest WindowInsetsControllerTests
Change-Id: I8cd8faac70dd5a15d779d2c983f0a0ea5d6bbd8e
Move it to ViewRootImpl and rename it: mDispatchedSystemUiVisibility
with default value 0 in the new insets mode instead of -1. Because
mCompatibleVisibilityInfo.globalVisibility will always be updated in the
new insets mode, we don't need the -1 value to detect the change from
non-zero value to zero dispatched from the server.
Bug: 118118435
Test: atest LayoutTests
Change-Id: I45064bdcdca37b9a2b30d82bb9d9c84e45732029
1. Keep a strong reference to the contentCallback.
2. Make sure inflated() only allowed to be called once.
Bug: 146524826
Test: atest CtsInputMethodTestCases:android.view.\
inputmethod.cts.InlineSuggestionTest
Test: manual. Call inflate() twice and make sure the
behavior is expected.
Change-Id: Id9bd386269111d11a2b2c27e33832cac90061b61
Add a compatiblity param to the setFrameRate() api, so the system has
more info to decide the device frame rate when there are multiple
competing preferences.
I also changed the plumbing for setFrameRate() to go directly to surface
flinger, instead of through buffer queue. We're trying to avoid changes
to buffer queue code, to avoid disturbing the prebuilts.
Bug: 137287430
Test: Added new cts tests to verify behavior of the compatibility param.
cts-tradefed run commandAndExit cts-dev --module CtsGraphicsTestCases --test android.graphics.cts.SetFrameRateTest
Test: /data/nativetest64/SurfaceFlinger_test/SurfaceFlinger_test --gtest_filter='SetFrameRateTest.*'
Change-Id: I9123afee2ba63d01ff35fb2b257a1ee0e4928ddd
View could be embedded within a SurfaceView via SurfaceControlViewHost
now. We need to apply the screen matrix to the bound after that since
the host SurfaceView may scale or offset the embedded view. Otherwise,
the boundsInScreen would be incorrect.
Bug: 148821260
Test: a11y CTS & unit tests
Change-Id: Ia590cfd20b26a9d9c58b8499098d25ad9d67f261
If the BLAST surface control was not returned, fail early instead of
trying to update the BLAST adapter
Bug: N/A
Test: build, boot, turn BLAST on, no crash
Change-Id: Ib921fdb8c5313519ff0b09304d1e0359fcc7c018
Temporarily disable compositor shadows for freeform until root task has the correct/non-fullscreen bounds.
Fixes: 148807641
Test: adb shell settings put global render_shadows_in_compositor 1
Test: go/wm-smoke
Change-Id: I10371d2a2977bc4d10204d3cf4b052da5165e0e6
Added a render service in ExtServices to connect to the renderer in
androidx.autofill for inline suggestion slices.
Cleaned up old UI rendering code that lived in system_server.
Bug: 146453086
Test: atest ExtServicesUnitTests
Change-Id: I25a7ea438afe524683671c850625ae80dacccfaa
ScreenRect is position in current window. However, it results in the
incorrect bounds if the window isn't from (0, 0). We need to update
it with bounds on screen instead.
Bug: 149539748
Test: a11y CTS & unit tests
Change-Id: I3cb07656a2c87e5f4fd1cba78463b1135c959bd4
