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
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
