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 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
references during the Content Capture Sharing.
Motivation: if the remote app is killed, we don't want a possibility of
system server holding a stroing reference (through a reference chain)
to large objects in that app. Therefore what's send in the binder has to
be a weak reference. And we will store a hard reference to those objects
in the client app's static context.
Storing hard references to objects in system_servier is less critical, because that is not going to be killed.
Bug: 148265162
Test: covered by CTS tests
Change-Id: Ie561aab6019d191cf8659fb350e045089e7781ed
(cherry picked from commit 13f65b2974)
* So that autofill manager service can use it to control the IME
visibility to better support the inline suggestion workflow
Test: m -j, also manually verify with local changes
Bug: 152082216
Change-Id: I5c4b236bedeced8ff714090effce46161ee1170a
- Do not reset system bar visibility when changing control target
- Do not apply hide transaction when gaining control, because that
may result in a single-frame flicker because it will conflict with
the animation
- Check requestedVisible instead of InsetsState.isVisible in
DecorView to avoid drawing the bar backgrounds transiently
- Abort transient mode when focused win changes.
Bug: 150195782
Bug: 152014877
Change-Id: I8bc9cdc89ce7364984ade8146e12a706ad5e8edb
