Add Syncer class that allows callers to add desired syncs into a set and
wait for them to all complete before getting a callback. The purpose of
the Syncer is to be an accounting mechanism so each sync implementation
doesn't need to handle it themselves. The Syncer class is used the
following way.
1. SurfaceSyncer#setupSync is called
2. addToSync is called for every SyncTarget object that wants to be
included in the sync. If the addSync is called for a View or
SurfaceView it needs to be called on the UI thread. When addToSync is
called, it's guaranteed that any UI updates that were requested before
addToSync but after the last frame drew, will be included in the sync.
3. SurfaceSyncer#markSyncReady should be called when all the SyncTargets
have been added to the SyncSet. Now the SyncSet is closed and no more
SyncTargets can be added to it.
4. When all SyncTargets are complete, the final merged Transaction will
either be applied or sent back to the caller.
The following is what happens within the SyncSet
1. Each SyncableTarget will get an onReadyToSync callback that contains
a SyncBufferCallback.
2. Each SyncableTarget needs to invoke SyncBufferCallback#onBufferReady.
This makes sure the SyncSet knows when the SyncTarget is complete,
allowing the SyncSet to get the Transaction that contains the buffer.
3. When the final FrameCallback finishes for the SyncSet, the
syncRequestComplete Consumer will be invoked with the transaction
that contains all information requested in the sync. This could include
buffers and geometry changes. The buffer update will include the UI
changes that were requested for the View.
Test: SurfaceSyncerTest
Test: SurfaceSyncerContinuousTest
Bug: 200284684
Change-Id: Iab87bff8a0483581e57803724eae88f0a3d96c8e
This is a semi-automatic change.
See https://errorprone.info/bugpattern/JdkObsolete for the rationale.
Test: make
Bug: 221046110
Change-Id: I15328005007ddc58f56604f6064c30fbed2c01a6
(cherry picked from commit 1c8715261d)
Merged-In:I15328005007ddc58f56604f6064c30fbed2c01a6
We first need to dispatch insets, then we can measure so we don't
need to immediately measure again.
Fixes: 210881360
Bug: 190379081
Test: Presubmit, Boots
Change-Id: Id40a083dd2e122ca71a96213e94b5bbbb45d596d
Use device config to control whether autofill dialog feature is enabled.
To support this, the autofill namespace of DeviceConfig needs to be exposed
for AutofillManager to read in the app thread.
There are augmented_autofill_mode, smart_suggestion_supported_modes and
compat_mode_allowed_packages existed in autofill space. These can be made
app readable.
Bug: 210926084
Test: atest android.autofillservice.cts.dialog.LoginActivityTest
Change-Id: Idfb846656a0c26eba1db4f8ef6ec427ae4ca666d
As the legacy flag SHOW_FORCED when calling showSoftInput keeps
remaining soft-keyboard visible, even though switching focus to another
application the situation still remains, unless someone calls
hideSoftInputFromWindow explicitly.
In case SHOW_FORCED flag affects the next client to keep IME visible and
hard to handle for the app developer, we introduce a platform
compatibility flag, when enabled, if the current client is leaving due
to the next focused client, in IMMS side will clear mShowForced flag when
the next client's targetSdkVersion is T or higher.
Also, deprecated SHOW_FORCED flag with updating the reason in
the documentation.
Fix: 214016041
Test: atest KeyboardVisibilityControlTest#\
testShowSoftInputWithShowForcedFlagWhenAppIsLeaving
Change-Id: I47efe5cb02ba69cbe018619e5bdc8f3995a55b4b
Otherwise the results can be quite confusing, each time we call
getSurfacePackage it returns a new SurfacePackage but after releasing
the first one all the others become invalid. This normally isn't
noticed as SurfaceControlViewHost is frequently used only in
cross process scenarios so the additional step of parcelling
can prevent this issue from occuring.
Bug: 196926363
Test: SurfaceViewSurfacePackageValidatorTest#testSurfacePackageNoFlicker
Change-Id: Id77f6daab4bb80d4d23d40d24d74b39bd694f350
This CL undoes part of [1] making removing a local variable.
[1]: Id4c85be1c0eab51f167ba00fc355386f852c424d
Test: make
Change-Id: I6b890e5536c17dd53722e2c3a781c85dd9d6bdf0
(cherry picked from commit d90033999f)
Merged-In:I6b890e5536c17dd53722e2c3a781c85dd9d6bdf0
When a freeform app launched and focused, but its window is not ready,
the input focus stays on the window of the previously focused freeform
app. The focus should be removed from the previously foccused app, so
ANR can be triggered correctly.
Bug: 216852742
Test: atest AnrTests#slowOnCreateWithKeyEventTriggersAnr
Change-Id: Id00c147ffab9b11fb2abdf0f3020bc017a31bea7
We now allow OEMs to extend the window to cutout area in below cutout
mode, only if the cutout overlaps at most 16dp with the app windows.
- LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFUALT
- LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
Bug: 218603390
Test: make
Change-Id: I8c83cde40f321de2a301b5865445ff765c824d43
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Bug: 217973491
Change-Id: I0b5741b376e042537c37ec34644e0a048eb4bfe0
The caller such as SurfaceView can optionally apply destination
frame changes if they wish to synchronize buffer scale with other
scales in the hierarchy. This is hard to synchronize if the buffer
scale changes, since in fixed scaling mode we want the destination
frame to be applied when a buffer of the new size is queued.
This approach is brittle because SurfaceView does not have control
over the buffer production and the app can get into a scenario
where there is scaled incorrectly.
Fix this by configuring BBQ to always apply destination frame
changes or always defer to the caller. If the scaling mode is freeze,
then BBQ will set a flag to ignore the destination frame. This
allows us to synchronize destination frame changes with scale
applied by a parent and avoid unwanted scaling if the scaling
mode changes to freeze.
Test: atest SurfaceViewTest
Test: go/wm-smoke
Bug: 217973491
Change-Id: I5226c304bae9dde890306f8528dfeabf6b015a32
APPEARED and DISAPPEARED events should be sent when a title is first
given and nulled respectively, following the Javadoc.
Test: Manual, atest AccessibilityPaneTest
Bug: 133131221
Change-Id: I41cd2548aa949c7ce320e228c2b07ef04ea0298b
When the pane title changes, the view may not be actually visible on screen.
Check parent visibility before sending a pane event.
Bug: 133131221
Test: manual check to ensure we don't receive title event, atest AccessibilityPaneTest
Change-Id: I8bad8f742cc3e8f4d906c2b6fe80a3516c900ef1
This is a follow up CL to my previous CL [1], which introduced
InputMethodManager#invalidateInput(View).
One thing I overlooked is that apps may call that API even before
InputMethodManager#mCurrentInputMethodSession,
which results in a NullPointerException.
With this CL, such a case will be gracefully fallen back into
InputMethodManager#restartInput(View)
like other cases when IMM#invalidateInput() is not available.
[1]: I3161755779080f98bcef0e47dd0c5247d8a3a256
daa6695c2e
Fix: 213350732
Test: atest CtsInputMethodTestCases:InputMethodStartInputLifecycleTest
Change-Id: I67458494b3069498a1395e3278f6a975e821e610
The java API is not consistent with the now deprecated native ASurfaceTransaction_setGeometry API. The existing functionality can be
better composed with the available API to set position, scale, transform
and crop.
Bug: 220336806
Test: presubmit
Change-Id: Ib2bf75876e2ce5e700da3085fab66218723ff54e
If a View detaches, its keep clear areas should no longer be considered
when placing a PiP.
Bug: 209577354
Test: atest KeepClearRectsTests#testIgnoreKeepClearRectsFromDetachedViews
Change-Id: I0caa74d4bef2ee157fc3f48747788e30752d09ad
- updateAboveInsetsState() now updates the entire hierarchy everytime
it is called.
- updateAboveInsetsState() also takes care of passing the local Insets
Sources to the insets-state of every children in the subtree of the
WindowContainer for which the API was called.
- addLocalInsetsSourceProvider() adds a new local InsetsSourceProvider
to the WindowContainer.
- removeLocalInsetsSourceProvider() removes a local InsetsSourceProvider
- Made InsetsSourceProvider abstract and added a
WindowContainerInsetsSourceProvider to be used instead. Eventually
all the window specific logic will be moved to WindowContainerInsets-
-SourceProvider.
Bug: 199449177
Test: atest InsetsStateControllerTest WindowContainerTests WindowManagerServiceTests
Test: atest ActivityRecordTests
Change-Id: I8d93b739df6d5f18a0d2219d9b00d96a2829746c
JankData.PREDICTION_ERROR is asserted when SF vsync calculation
is incorrect and should be attributed to SF missed frames.
Bug: 211763914
Test: SF unit tests
Change-Id: I332480ad1017c220501ed938319f8b2fbfe22826
This new attr will allow IME to specify whether they support inline suggestion with touch exploration
Fixes: 207007377
Test: atest android.view.inputmethod.InputMethodInfoTest
Change-Id: I1fa36d7fd57a9b25838d4dd48243c19630495648
