We just need to forward the WindowSession call to the internal
method we already support.
Bug: 213603716
Test: Existing tests pass
Change-Id: I692d321a96b5278c75bceb14d5b38459d360b4b9
Changed the names of existing display mode APIs.
Added similar APIs in Display class, so that
resolution and refresh rate settings can be pesisted for each display.
The APIs can now be used to set display mode (or only resolution or
refreshRate).
Bug: 206911689
Test: atest DefaultDisplayModeTest
Change-Id: I19655fc347d36e45b5664e2b6faa3d58b5d7004c
We add a control interface in to surface-package which allows
the embedding process to dispatch events back to the embedded
process. So far we support forwarding configuration changes,
and dispatching a detach view hierarchy message.
Bug: 213603716
Test: Existing tests pass
Change-Id: I7d68628d845b5da687568ffa20529ce2a7772495
This will let the task bar and all other windows provide an insets frame
smaller than the window's frame. This is a regression caused by the
flexible insets change.
If the window provides both internal insets and the content insets, both
of them will be deducted. A comment is added to the
provideInternalInsets to avoid the mis-use. There's a long term plan to
change the functionality of the provideInternalInsets. Will have it in
the follow-up patches.
Bug: 212221722
Test: atest DisplayPolicyTests
Change-Id: Ib9e414627992b46b1a1d0afa314ea180dfdbc4d6
Introduce InputMethodManager.startStylusHandwriting(View) API
and IME lifecycle.
Bug: 203086136
Test: atest StylusHandwritingTest
Change-Id: I7b066c2841b713e7a00ae2ea4ca0ce04aad751c6
Throw an illegal argument exception any time a Paint with
a RuntimeShader is attempted to be drawn into a software
canvas. Also mark that a Picture that uses a RuntimeShader is
properly marked as requiring hardware acceleration.
These tests check that the use of RuntimeShaders trigger
Bug: 189102731
Bug: 201546136
Test: atest CtsUiRenderingTestCases:RuntimeShaderTests
Test: atest CtsGraphicsTestCases:RippleDrawableTest
Change-Id: I663e2bc06a3b475f0bb256ce6a9c00c6432ffa42
Tunnel through SurfaceControl to determine whether the HWC has this
capability. This allows clients (i.e. SystemUI) to know whether they can
use Composition.DISPLAY_DECORATON. If so, they may want to render
differently (i.e. in A8). See Ib948c38ee189877eda675a6342cb70099f66122b
for an example.
Bug: 193170859
Test: manual
Test: TODO
Change-Id: I9904452b6408199bb1f86de9e21132e4d4444e1a
When disabling batching input, we should post the action to consume
batched events to prevent it would be handled before current event.
Bug: 189241600
Test: atest WindowInputTests --rerun-until-failure
Change-Id: I87aaa2574a27368f88df1aba3f2eb769a8e8f36b
(cherry picked from commit a0ef47223c)
There is a flicker in wallpaper picker due to a recent change where
SurfaceView creation changes were synchronized with VRI frame. This
breaks wallpaper picker because wallpaper picker doesn't actually
draw into the SV surface, instead they attach a surface package.
The current implementation meant the SurfacePackage would be visible
before it was scaled correctly.
This fix applies the visibility changes along with the scaling changes.
Test: steps in b/211945947
Fixes: 211945947
Change-Id: I4e5107ac2caf634429e1bec3201fdcaa8f5f92bc
This CL only implement the handwriting initiation for milestone 1:
a) handwriting is only initiated for a focused editor.
b) user must start handwriting within the editor's boundary.
Bug: 209854913
Test: atest FrameworksCoreTests:HandwritingInitiatorTest
Change-Id: Iab6d83f58aa74f0af8091731c80bbdb2eb29c024
There are 3 milestones in this feature.
1. Refactor the callbacks for Accessibility in WindowManagerInternal.
2. Implement this feature in such new architecture.
3. Implement the setting choice in preference page.
This CL is for the 2nd milestone.
We move the window magnification to the typing focus' center position
based on the condition of whether a user takes control or not. We only
make a movement when the control is not taken by a user or we don't
preform the movement for the window magnification.
There are 2 methods for a user to take the control.
1. A user use 1 finger to drag the window magnification.
2. A user use 2 finger to drag the window magnification.
There is 1 method for a user to release the control.
1. When IME is shown, the control would be released.
So, we can decide whether we should make a movement to typing focus
given the condition of who take the control.
Bug: 194668976
Test: atest MagnificationControllerTest
atest WindowMagnificationTest
atest WindowMagnificationControllerTest
atest WindowMagnificationManagerTest
Change-Id: I145f893d412b74c20afe1685449370d1dba99961
Some apps or games could use the combo keys such as holding Ctrl or Alt
to trigger its own shortcut or behavior. To prevent the system shortcut
might be handled before dispatching to the app, we move these keys
handling to 'dispatchUnhandledKey' when the app didn't handle.
This will also fix the corresponding state when the modifier key is
released.
Bug: 156619364
Bug: 213096704
Test: atest AppKeyCombinationsTest
Change-Id: I42770045c61ad6396b27132b8a61d34fc121d77e
Since we now support long edge cutout, the description of this API is
out of date.
Bug: 211939507
Test: make
Change-Id: I04c4c34e56c4e8b8d466e05cf60e89da31d6cc9b
