Introduce InputMethodManager.startStylusHandwriting(View) API
and IME lifecycle.
Bug: 203086136
Test: atest StylusHandwritingTest
Change-Id: I7b066c2841b713e7a00ae2ea4ca0ce04aad751c6
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
Alternative approach to fab15e55446080bdcfc05ba315e8ef914b0a6f65 which
was racy because the disconnect callback is called without the
BQ lock and the client can continue to modify the BQ state after
disconnecting from the queue.
This approach resets the BQ and BBQ states when the SurfaceControl is
updated. This solves one concrete problem of not relying on the old
SurfaceControl to be destroyed in order to release the currently presented
buffer back to BQ.
In addition this change resets the sync state in BBQ with the rationale
the system does not want to sync on buffers presented on an older
SurfaceControl.
Bug: 197269223
Test: atest BLASTBufferQueueTest
Test: labtest ag/16407859 cf-foldable * 3 (b/197269223#comment40)
Change-Id: I137d3284c4e9216963f9c672f192afd334501ee5
FrameCallback sends back the syncStatus and allows the caller to return
a FrameCommitCallback. This is so the caller can evaluate the results of
the sync and determine if it wants to continue waiting for a commit
callback. In cases, where the sync has failed, there will never be a
commit callback so the caller can avoid waiting.
This is partically helpful for VRI because it wants to sync with a frame
that will draw, but also doesn't want to get stuck indefinitely waiting
on the callback. VRI can check the syncStatus and only handle blast sync
and/or reportDraw when its determined that a draw will happen.
This allows VRI to remove frameCompleteCallback since it can now wait
until a buffer has drawn instead of when the vsync has completed. This makes
sure it waits on FrameDropped since that result indicates HWUI will draw on
the next vsync
Test: BlastSync
Bug: 200284684
Change-Id: Ic6e2f08ea21ac8a1634a3389c927fcb68ede3f7b
The default value for DISPLAY_DECORATION is false. If there's a new
SurfaceControl, we only need to set the flag if it's true. This avoids
applying an unnecesary transaction.
It also prevents a boot failure which is independently fixed by
Ib11d46439db57b90486bad07dd90f2cf0822182a.
Bug: 211797674
Bug: 211835607
Bug: 212402133
Test: boots
Change-Id: Iccb662f9a6312b547b3d28fa1f5c1e9ff5dce9eb
The first time this topic landed, it resulted in b/212402133. We avoid
running into this bug with Ib11d46439db57b90486bad07dd90f2cf0822182a.
Original commit message:
When passed to native, this flag will tell a Layer that it should use
Composition.DISPLAY_DECORATION.
Bug: 193170859
Test: manual
Change-Id: I7f1685eb7dc57271f532065dcd1d4dcc449c5cb0
This change refined the FloatingToolbarPopup to allow the local and
system implementation. Use the flag to control which implementation
will be used. Use the local implementation as default, we will switch
the system version when it is done and stable.
Bug: 190030331
Bug: 205822301
Test: manual. The toolbar still work after refinement
Test: atest TextViewActivityTest
Test: atest TextViewIntegrationTest
Ignore-AOSP-First: new feature for T.
Change-Id: I191cb02fc4857855f5b63bdab21c014fa0879a0c
When work profile disable by quick settings, the
user would be locked then we cannot query installed
input method lists for work user by existings API
InputMethodManager#getInputMethodListAsUser().
Adding a new API to query input method services
regardless of the user state. This API currently
only used by Settings, it shouldn't affect the
original behavior for other usages.
Bug: 210083408
Test: verify we can get input methods list after
disable work apps by quick settings
Test: atest CtsInputMethodTestCases
Change-Id: I54d5dbec7e76d6a68935007ed3af0641f717a7c5
We convert the InputFeatures flags into AIDL enums that will have values
generated in both native and java code so that the value only has to be
defined once.
Bug: 162194035
Test: build, presubmit
Change-Id: I8176265079292ee969c409ddd52676a52f208601
A stylus interceptor is a window that receives all stylus events within
its touchable bounds, while letting all other events be dispatched to
windows behind it. This makes it possible for the framework to create a
stylus interceptor on top of another app to implement handwriting
recognition.
The feature has no effect when the window flag FLAG_NOT_TOUCHABLE is
not set.
The feature has no effect when the window is not a trusted overlay.
Test: manual
Change-Id: Ia481ee8d831643bc99445b47659a7f5e9875c388
