This reverts commit 8c56ac6b94.
Underlying issue has been fixed:
Test: InsetsControllerTest
Bug: 152071027
Change-Id: I2b80de7067bf688a6b36233b9a1e92e2cf31c148
If BLAST is enabled and we somehow end up in positionLost or
setParentSpaceRectangle without having called setUseBLASTSyncTransaction
we will end up putting operations in to a Transaction which will never be
applied. This condition should be considered a bug, but it's best to
defend against it. To compensate, rather than checking the global
use BLAST flag, we check if the current draw is actually using
BLAST.
Bug: 152663327
Bug: 152780239
Test: Existing tests pass
Change-Id: I3c05b83400b59be82a339933fc8ef1382d4f0e21
If visibility changes we will try and hide the Surfaces from
the RT. We want to sync this with ViewRoot drawing so
we enable BLAST sync for the next frame in this case.
Bug: 152663327
Bug: 152780239
Test: Existing tests pass
Change-Id: I9cd157954a3ce87a8f95a7be97d6d5c7f324327b
When we call mSurface.transferFrom(getOrCreateBLASTSurface()) we
always end up incrementing mSurface.generationId, because
BLASTBufferQueue.java::getSurface will always return a new native
wrapper object. We had a similar situation with
mSurface.copyFrom(mSurfaceControl), and had to build IGBP
comparison in to the native method. Here though, it's easier
to just rely on the stability of the Surface (never changes
for the lifetime of the BLASTBufferQueueAdapter) to avoid
duplicate calls to transferFrom.
Bug: 152501005
Test: Existing tests pass.
Change-Id: I64b9a6ae3cabfa75974e040460638417bfac6845
Currently every call to getOrCreateBLASTSurface produces a transaction.
This transaction has two parts, both of which can be eliminated:
1. The first is the reparent. This was written when the
client allocated the BLAST SurfaceControl, but now the WM
allocates it and it has the correct parent to start, so
we can just eliminate this.
2. Showing the surface. We can eliminate this by just showing
the surface by default.
Bug: 152501055
Test: Flip BLAST flag. Play.
Change-Id: If6e28e9153a09909fb3bb061980deb82c132dd5a
...in order to make WindowInsets.equals consider source missing
and source not providing insets the same.
Fixes: 152822955
Test: InsetsAnimationTest
Change-Id: I31cb0278f45c38fb788d4f2bdefb1a13b6870216
Previously app ops weren't showing in conversation notifications
Also made sure that they show in case the app name is long.
Additionally this fixes the coloring of the sender name.
Fixes: 150905003
Test: atest SystemUITests
Change-Id: Iae8026e7efdec8c207d1984dac4ee089abe116b9
When using controlWindowInsetsAnimation to close the IME,
delay reporting this to the IME until the animation is actually
finished. Otherwise, the IME will self-hide and start a transition
that breaks the just-begun app-driven transition.
(Regression from I7f6098a61a5942795ffd33a60329e4dd5fb5d6cb which
changed InputMethodService to hide itself in reponse to notifyHidden)
Bug: 151980214
Test: make WindowInsetsTests, ensure that dragging the IME closed doesnt get cancelled
Change-Id: If4e64cc78742a4e1e8c98137bd97d65dd567f674
To make sure legacy insets are correct always.
Test: Open Message, go to attachments, reopen IME
Bug: 152851108
Change-Id: I9ae0930645ca4331d362af7db9ab77bf49d74edc
Make sure finish callback gets called when
applyChangeInsets gets called synchronously from
scheduleApplyChangeInsets
Bug: 152071027
Test: InsetsAnimationControlImplTest
Change-Id: I6808b3527f1d2e15de681c5260208d238dcf53e2
With the introduction of insets types we no longer support consuming
individual insets.
Instead we consumed all insets, regardless of whether you consumed
stable or system insets - but that led to compat issues.
On Q, consumeStableInsets was almost always a no-op anyways, because
stable insets already came pre-consumed during dispatch.
This change makes consumeStableInsets() a no-op to more closely match
that behavior.
Bug: 152033222
Test: atest WindowInsetsTest
Change-Id: Ic48ee7386320fc16449ac79435b69305a8132bf8
The janky caused by SurfaceFlingerVsyncChoreographer does not work
reliably. Sometimes it didn't update but sometimes update twice per
frame so cause janky.
Fix this by removed using SurfaceFlingerVsyncChoreographer and use
real surface flinger sync signal to update screen.
Bug: 150874701
Test: enter split mode and drag divider to observer janky
Change-Id: I5a8bce36738a97b0ddaf4c4e77949eb5295b4894
The controls are copied previously in collectSourceControls and
so this copy is unnecessary.
Bug: 150805473
Test: Existing tests pass
Change-Id: I98b51b4372ace95036e25e806d1ab646d2df7879
Since we copy the InsetSourceControl to the animation
runner, we don't need to release the InsetsSourceConsumer
copy from the render thread, as it wont be used there.
Bug: 150805473
Test: Existing tests pass.
Change-Id: I03cb69e17e036237410472e8b4601b61fc40bc0e
* changes:
Indented the conversation action list
Fixed some issues where conversation badges would not be visible
Improved the animations of the conversation badges
Important conversations now also transform into the shelf
Adapted Shelf algorithm to also use conversation icons
When introduced ImeFocusController, we originally would like to
resolve CL[1] enabling IMM#focusOut issue to archieve auto-hide IME when
no more view with focus.
However, some problems that we end up to disable because:
1) Bug 152230171 shows the current view focus may be cleared temporary
when in touch mode, closing input at this moment isn't the right way.
2) Bug 148974380 hits a case when tapping SearchView which is inside
of ListView, several focus in/out events comes up and may break input
connection unexptectly because wheather the next served view is no longer
coming or not is unpredictable from this callback.
Even we fixed the issue with CL[2] to tweak the next served view as
null only when the current served view lost focus, we still can't
guarantee that input connection won't break when current served view
lost focus by moved to other focusable view (e.g. popup window)
3) Setting the next served view as null when no more served view should
be handled more conservative in other special events
(e.g. view detached from window or the window dismissed).
[1]: I2228ae0c48ad3d9e0b55875f0dcb5ef8c55b0c5f
[2]: I9e90428387fcf43fbf86a8407de7535913202872
Bug: 152698568
Test: atest FocusHandlingTest
Change-Id: I6e38c4425233cea4b0a90285a2dc476b76c20979
- make sure we only dispatch the controller in onCancelled after the app has seen onReady
- return a linearly interpolated getFraction() if there is no interpolator instead of -1
Bug: 118118435
Test: atest WindowInsetsAnimationControllerTests
Change-Id: Iccd0b6246b4cdc250f3111409821c1dac53c694e
Previously the algorithm would only work with a header
and the icon wouldn't transform into the shelf.
This is now fixed.
Bug: 150905003
Test: add conversation notification, observe normal transition
Change-Id: I533b8f06bee29ee93888d748808b4313fef338e8
This error showed because DecorContext uses application context
to get WindowManager. This CL changes to use context to do so.
Also rename fields in DecorContext because we actually can pass any
context in "activityContext."
Note that most cases of misuse WindowManager is covered by [1].
We can guarantee that WindowManager can be obtained by mContext.
[1]:I52aa0c4a02b7da018aa10f1473e1616564296e41
Bug: 150632074
Test: manual - enable strict mode and check the error log not shown.
Test: atest DecorContextTest
Change-Id: I558a2819e5928a802b897a130cfc3262115b9935
Old APIs are kept and marked as @hide + @removed to maintain
compatibility.
Bug: 151262653
Test: manual verification
Change-Id: Ia50a1f87c194211be5256e948d43fb54c1cbf941
