summaryrefslogtreecommitdiff
path: root/core/java/android/view/InsetsAnimationControlCallbacks.java
Commit message (Collapse)AuthorAgeFilesLines
* Prevent adding methods in WindowInsetsAnimationControllerTiger Huang2021-09-031-1/+1
| | | | | | | | | | It is a public interface which should not have different versions sharing the same API level. This CL moves the methods to an @hide interface. Fix: 198614722 Test: atest android.signature.cts.api.current.SignatureTest Change-Id: Ib02708aeb1ec960bda20b6b60d4df6f0c9b4d9d6
* Invoke insets animation callbacks when resizing system barsTiger Huang2021-07-211-5/+5
| | | | | | | | | | This gives the app a chance to react to the animation of resizing system bars. Fix: 191269755 Test: atest InsetsAnimationControlImplTest InsetsControllerTest InsetsStateTest Change-Id: Ibf47047c131867983064bef4e9ac011daf66ea18
* IME animation: hide IME-related navbar icons until perceptibleAdrian Roos2020-06-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | During transitions and while the IME is controlled by the app, the IME may be "visible" as far as the IME framework is concerned, but not actually perceptible by the user due to offsets or alpha applied to the leash. This may lead to out-of-place navbar symbols for the IME, especially in gesture nav. To avoid this, the ImeInsetsSourceConsumer now notifies the IMF of whether it has made the IME unperceptible to the user. For now, we ignore the cases where the IME is controlled by something other than the client window - in that case, we just revert to the previous behavior of it being always considered perceptible. Fixes: 158079255 Test: manual, launch email compose activity, observe that back button only indicates once IME appears Test: atest InsetsAnimationControlImplTest Change-Id: I4dc9d6513d0559156f7da39244f3fc5ebc952ed4
* WindowInsetsAnimation: Synchronously dispatch window insets animation callbacksAdrian Roos2020-04-011-1/+3
| | | | | | Test: atest WindowInsetsAnimationControllerTests Bug: 152617481 Change-Id: Ie002f2e605f841563d8c2669f949be3ddd666146
* InsetAnimationControlImpl: Copy SurfaceControlRob Carr2020-03-131-0/+6
| | | | | | | | | | | This way the lifetime can be bound to the animation. Otherwise the InsetController owns the lifetime, and it can be challenging to synchronize the two (we would need to update all the running animations when we rebuild the control list). Bug: 150918857 Test: Existing tests pass Change-Id: I86017b2eaee29ab0d8174479d187c9b7dd014305
* Use separate thread if app doesn't listen to animationsJorim Jaggi2020-03-111-4/+3
| | | | | | | | | | | There is no need to introduce jank risk and run the inset animations on the main thread if the app doesn't listen to animation events. In that case, move the animations onto a separate thread. Bug: 118118435 Test: Inspect systrace Change-Id: Ib6e4b4ce8e9dd8e27761ced6eb8d7700b6236a32
* WindowInsetsAnimation: Clean up APIAdrian Roos2020-02-171-6/+6
| | | | | | | | | | | | | | | | | | | | | Fixes issues the app developers have raised with the WindowInsetsAnimation API: - it really makes more sense to have the Animation as the outer class, and the Callback nested within - it was not obvious previously that multiple animations could be running at the same time. A new argument to onProgress now makes this abundantly clear by passing in the list of running animations. - The dispatch mode really fits better as a final property on the callback, rather than it being queried once from a getter. Also fixes lint warnings. Fixes: 143556682 Test: make checkapi; atest WindowInsetsControllerTests Change-Id: I8cd8faac70dd5a15d779d2c983f0a0ea5d6bbd8e
* Remove getState from InsetsAnimationControlCallbacksJorim Jaggi2020-01-281-6/+0
| | | | | | | | | No longer needed since we either show or hide all the types when finishing an animation. Test: WindowInsetsActivity Bug: 118118435 Change-Id: I2323403d375cdf781b34b4d2107d3151299eb995
* Correct layout/draw/animation interleaving for insets callbacksJorim Jaggi2020-01-101-4/+15
| | | | | | | | | | | | See WindowInsetsAnimationCallback.onPrepare for detailed description of new behavior. Also rename InsetsSourceConsumer.setVisible to setRequestedVisible to communicate that this is client intent vs. current state. Test: windowinsetstest application Bug: 111084606 Change-Id: Id35c60e0f59a8aa4f0d300220391d1e2b96a91fd
* Decoupling InsetsAnimationControlImpl and the clientYunfan Chen2019-12-271-0/+55
Currently InsetsAnimationControlImpl is heavily rely on InsetsSourceConsumer and InsetsController on the client side, which caused difficulties to the server to re-use the code. Decoupling it to make it re-usable. This patch made the following changes: 1. Introduce a callback interface to let InsetsAnimationControlImpl talk to InsetsController. 2. Use InsetsSourceControl instead of InsetsSourceConsumer in the InsetsAnimationControlImpl. 3. Remove all the consumers in the InsetsAnimationControlImpl. Test: atest InsetsAnimationControlImplTest Test: manual test with the new insets API, it works as expected. Test: go/wm-smoke Test: atest FrameworksCoreTests:InsetsControllerTest Change-Id: I30f5aa73ff31e07c0dd8d61edbb208f16c5a6775
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 02:13:32 +0000