Right now, multiple display devices can share a layerstack.
This means that when constructing InputWindowInfo, its
impossible to know which display transform matches the
display viewport that inputflinger dispatches against. To
remedy this, have displaymanager inform surfaceflinger
which displays "receiveInput" using the same logic that
controls which display viewport it sends to inputflinger.
Bug: 179274888
Test: atest SetDisplayStateLockedTest
Change-Id: I85f1d0ac6fcf9c37a523eb80ed02afeff555c93d
If the surface position is changed during the insets animation,
the surface position of the controls in the animation should be updated.
Otherwise, the cached position in the animation will overwrite the
newly-updated leash position.
Fix: 177925500
Test: Steps in the bug.
Test: 1. Open Window Insets Tests -> Window Insets Controller.
2. Click on the [IME INVISIBLE] button.
3. Click on the [STATUS BARS VISIBLE] button during IME animation.
See if the position of IME (Gborad) is correct.
Change-Id: I7441426a41019996651220e86ca90dd416ef9498
Apply a simple text alpha animation when toggling between original and
translated text. The text is fully faded out, then swapped to the new
text, then the fading is reversed.
Quick toggles are handled by ending the previous animation (which resets
the alpha value) when starting a new one. If the toggle is extremely
fast (<250ms for the currently defined animation duration), the text
stays in it's original state instead of swapping back-and-forth. This is
arguably not ideal, but anyway not worth the complexity for fixing.
There is an unhandled edge case where if the color is changed by the app
during the animation, the app's change would get overridden. It should
be rare and doesn't seem very important to fix.
Bug: 178651829
Test: atest CtsTranslationTestCases
Test: manual - across several apps, while scrolling, concurrently
interacting with the app, concurrently closing the app, selecting text
during the animation (with animation speed slowed down to see the
effect).
Change-Id: I08a26de2253bb345f01186a6748b2d0ff6c2a419
This can happen if UiTranslationManager#startTranslation is called more
than once for the same view. If the same TranslationResponse is
returned, it can simply be ignored.
This is preferable to ignoring duplicate ViewTranslationRequests, since
the Response is already cached. The TranslationService can cache
translations, so duplicate requests isn't an issue.
Ideally, the platform intelligence shouldn't issue multiple requests for
the same view.
Bug: 144292180
Test: atest CtsTranslationTestCases
Change-Id: I0bba4a19284a61a9c7a5b79c71b4f42ddffe4e32
Bundle doesn't override equals(). In TranslationResponseValue, the
Extras is used as a simple value type, so contents can be compared.
Bundle.kindofEquals probably works here, but this change just makes it
work for empty bundles for now, to fix a bug in animation.
Bug: 144292180
Test: atest CtsTranslationTestCases
Change-Id: I68daac8cafceb1aa446ee89ba1405595b22e6213
- Disallow callers from concurrently modifying the exclusion rects
list after it's set by making a copy.
Bug: 166594759
Test: atest android.view.cts.SystemGestureExclusionRectsTest
Change-Id: I80183cf85d16ac669320cfda9ec9deed9e348e33
Some recycled views cached its layout and a relayout is unnecessary.
In this case, system still needs to notify content capture the view
appeared.
Bug: 177687849
Test: atest CtsContentCaptureServiceTestCases
Test: atest ContentCapturePerfTests
Change-Id: I480436c4fc3508b9eed485421a1cc778d55d5dde
In performTraversals, "params" may be null. In this case we were
not passing params to the WM indicating no changes (an obscure
artifact of the protocol). In R the WM would simply ignore this
however our updateOpacity logic in S is treating null as "translucent"
it seems easiest to just pass mWindowAttributes directly avoiding
the null case. While the opacity was broken, it seems an animation
was added to StartingSurfaceDrawer which depends on having a translucent
window. We also update this code to request a transparent pixel format
as would have been required in the R API.
Bug: 186555833
Test: Existing tests pass
Change-Id: I180bf1796bbb4b7049ae9811f674f31014c2a400
The issue was that: if navigation bar is requested to show while a
controller is playing an animation of hiding both status bar and
navigation bar, the animation will be canceled and will stay in an
intermediate state, and then, another controller will play an animation
of showing navigation bar. At the end, status bar will stay visible but
it should be invisible.
This CL fast-forwards the insets animation to the end state if it is
canceled.
Fix: 185459811
Test: Steps in the bug.
Change-Id: Id6ae321b6c153ed1d7155afd6111b193ac9c045c
